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ABSTRACT 


■ This  Technical  Report  describes  the  installation  and 
■aintenance  of  the  NIPS  360  Formatted  File  System.  It 
describes  the  hardware  and  software  requirements  of  the 
S/360  Operating  System  (OS) . The  functions  to  be  performed 
to  install  NIPS  360  FFS  are  presented  and  a detailed  typical 
2314  installation  is  included  as  a guideline.  The 
procedures  for  reporting  system  deficiencies  and  for 
periodically  updating  the  system  to  incorporate  system 
improvements  are  included.  — ___ 


This  document  supersedes  TR  54-77. 

TR  54-78  is  part  of  the  following  NIPS  360  FFS 
documentation. 
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Section  1 
INTRODUCTION 


This  document  describes  the  installation  and  maintenance 
of  the  NIPS  360  Poraatted  File  System. 

Section  2 describes  the  hardware  and  software 
requirements  of  the  systea. 

Section  3 describes  the  materials  included  in  an 
Installation  Package. 

Section  4 describes  the  functions  to  be  perforaed  to 
install  NIPS  360  FFS.  (A  detailed  typical  2314  Installation 
is  included  in  appendix  B.) 

Sections  5 and  6 describe  the  procedures  for  reporting 
system  deficiencies  and  for  periodically  updating  the  system 
to  incorporate  systea  improvements. 

Section  7 deals  with  the  special  reguireaents  of  the 
Terminal  Processing  (TP)  component. 

It  is  assumed  that  the  reader  of  this  docuaent  is 
generally  familiar  with  the  IBM  Systea/360  and  its  Operating 
Systea.  In  addition,  a conceptual  knowledge  of  NIPS  360  FFS 
is  desirable.  No  atteapt  has  been  aade  to  explain  or  define 
all  of  the  special  terminology  involved  in  these  systems. 
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Section  2 

SYSTEM  DESCRIPTION 


The  NIPS  360  PFS  has  been  designed  to  operate  on  IBM 
System/360  under  the  IBM  Operating  System.  This  design 
takes  advantage  of  the  upward  compatibility  of  the  various 
coaputers  in  the  Systea/360  family  and  allows  device 
independence  aaong  peripheral  equipment. 


2.1  Hardware  Requirements 

NIPS  360  FES  has  been  designed  and  programmed  for  an  IBM 
System/360  Model  50H  (256K  core  size).  It  will  also  operate 
on  a Model  40H  and  larger  models  of  the  System/360.  Without 
on-line  terminals,  it  will  operate  on  a Model  40G  or  50G 
(128k  core  size).  The  NIPS  360  FFS  can  use  magnetic  tapes, 
direct  access  devices,  card  reader/punches,  on-line 
printers,  a console  typewriter,  and  the  following  terminals 
for  teleprocessing  capabilities: 

a.  IBM  2260  Display  Stations  (Local  and  Remote) 

b.  IBM  2250  Display  Units  (Local) 

c.  IBM  1050  Data  Communications  Systems  (Dial-Up 
Remote) 

d.  IBM  2741  Communications  Terminals  (Nonswitched 
Mode) 

e.  IBM  3270  Information  Display  System (local  and  remote). 


A minimum  configuration  could  include  three  IBM  2311 
Disk  Units,  a card  reader,  and  an  on-line  printer,  although 
an  IBM  2314  Disk  Storage  Unit  is  considered  highly 
desirable.  Tape  requirements  are  related  to  the  user's 
requirements  and  range  from  none  to  a quantity  sufficient  to 
perform  the  largest  sort  the  user  may  require.  Disk  sorting 
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is  used  to  the  capacity  of 
available  to  the  system. 


the  d'  “’ect  access 


devices 


The  system 
Display  Control 
printer  and 
processing.  An 
supported  under 


will  service  an  unlimited  number  of  IBM  2848 
Units;  each  unit  will  support  one  1053 
eight  local  2260  terminals  for  on-line 
unlimited  number  of  -2250  terminals  are 
the  following  configurations: 


a. 

2250-1 

Each  terminal 

b. 

2250-2 

Up  to  four  ter 

unit 

c. 

2250-3 

Up  to  four  ter 

unit 

has  its  own  control  unit 
minals  for  each  2840-1  control 

minals  for  each  2840-2  control 


An  unlimited  number  of  3270  terminals/printers  are  also 
supported.  Each  3270  control  unit  may  have  up  to  32 
terminals/printers  attached.  Independent  3275  display 
systems  are  also  supported. 


2.2  Operating  System  Requirements 

NIPS  360  EPS  will  run  under  three  main  configurations  of 
OS/360 ' s: 

a.  Primary  Control  Program  (PCP)  - The  standard 
Operating  System  which  processes  one  job  at  a time 
in  sequence. 

b.  MFT-II  (Option  2)  - Multiprogramming  with  a fixed 
number  of  tasks  - a partitioned  core  system 
allowing  up  to  four  jobs  to  operate  concurrently  in 
independent  fixed-size  partitions. 

c.  HVT  (Option  4)  - Multiprogramming  with  a variable 
number  of  tasks  - a regional  core  system  allowing 
up  to  15  jobs  to  operate  concurrently  in  variable- 
size  regions. 

The  NIPS  360  PPS  is  not  restricted  to  any  one  level  of 
the  Operating  System  and  it  will  use  subsequent  releases  as 
they  become  available. 
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NIPS  3b0  FFS  will  also  run  on  a System/370  VSl,  VS2 
Release  1 and  VS2  Release  2 version  of  the  operating  system. 

Multiprogramming  capabilities  of  the  Operating  System 
permit  multiple  jobs  to  operate  concurrently  in  independent 
partitions  or  regions.  The  OS/360  data  management 
facilities  will  handle  all  system  and  user  data  storage. 
NIPS  360  FFS  data  files  can  be  organized  under  Indexed 
Sequential  Access  Method  (ISAM)  for  disk  files  or  Sequential 
Access  Method  (SAM)  for  tape  or  disk  files.  The  various 
system  libraries  will  be  stored  using  the  Basic  Partitioned 
Access  Method  ( BPAM ) . The  basic  graphic  programming 
services  of  the  Operating  System  are  used  for  the  Terminal 
Processing  (TP)  component  that  services  local  2260  and  2250 
display  terminals.  The  Basic  Telecommunication  Access 
Method  (BTAM)  is  used  for  remote  support  of  2260,  1050  and 
2741  terminals  and  support  of  3270  terminals. 

Users  who  do  not  require  TP  support  may  operate  the  NIPS 
360  FFS  under  the  Primary  Control  Program  (PCP)  option  of 
the  Operating  System. 

In  addition  to  the  basic  Operating  System,  the  following 
must  be  included  at  system  generation  (SYSG5N)  time: 

a.  Programs 

O ASSEMBLER  - F level 

O LINKAGE  EDITOP 

O SORT 

b.  Libraries 

o Macro  Library  - MACLIB 

o Sort  Library  - SORTLIB 

c.  Data  Management  Access  Methods 

o Sequential  Access  Method  (SAM) 

o Direct  Access  Method  (DAM) 

o Basic  Partitioned  Access  Method  (BPAM) 
o Basic  Graphics  Programming  Services  (needed 
only  for  the  TP  support) 

o Basic  Telecommunication  Access  Method  (BTAM) 

(needed  only  for  specific  device  support) 
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o Variable  Indexed  Sequential  Access  Method  (VISAH) 

The  following  say  require  that  special  provisions  in  the 
Operating  System  be  made  at  SYSGEN  time  depending  on 
installation  requirements: 

a.  NIPS  360 FF£ Supervisor Call (SVC) Routine 

Installations  that  operate  in  S/360,  and  S/370  VS1 
and  VS2  Release  1 environments  and  require  NIPS/TP 
support  must  reserve  a Type  III  SVC  at  OS  SYSGEN 
time.  The  TP  MONITOR  in  the  NIPS  360  EPS  TP 
component  uses  the  SVC  routine  and  is  distributed 
assuming  the  SVC  number  is  240.  The  SVC  number  is 
not  restricted  to  240  but  will  require  the  using 
installation  to  generate  a new  TP  Monitor  to 
recognize  an  SVC  number  other  than  240.  Section  7 
of  this  report  contains  detailed  information  on  the 
TP  component  and  its  installation.  Installations 
operating  S/370  MVS  verion  of  the  Operating  System 
do  not  need  the  TP  SVC  for  TP  support. 

b.  Generic  Unit  Names  - Generic  unit  names  are  used  by 
all  NIPS  360  FPS  procedures  to  minimize  the  number 
of  modifications  required  to  adapt  the  procedures 
to  an  installation's  hardware  configuration.  These 
generic  names  are  not  required  but  will  eliminate 
the  requirement  to  insert  unit  numbers  in  all  NIPS 
360  PPS  procedures.  Installations  should  include 
the  following  generic  unit  names  at  SYSGEN  time: 
NIPH  for  dish  work  space;  TAPE9  for  9-track  tape; 
and  TAPE7  for  7-track  tape. 


2.3  S/370  V S AH  Requirements 

On  an  IBM  System/370,  NIPS  will  perform  as  on  the 
System/360.  However,  the  user  has  the  option  of  processing 
direct  access  data  files  using  the  Virtual  Storage  Access 
Method  ( VS A M ) • In  order  to  perform  VSAM  processing,  the 
System/370  must  be  a Model  135  or  larger  and  have  OS/VS 
(operating  system/virtual  storage)  installed.  The  system 
must  also  have  the  dynamic  address  translator.  Direct 
access  storage  devices  which  may  be  used  include  the  IBM 
2314,  the  2319,  the  3330,  and  the  3333  devices. 
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Section  3 

INSTALLATION  PACKAGE 


In  this  section,  the  NIPS  360  FFS  user  is  given  as  much 
material  as  possible  to  assist  him  in  installing  the  system. 
This  not  only  includes  the  basic  NIPS  360  FFS  system,  but  a 
set  of  sample  JCL  used  to  install  the  system  and  a 
comprehensive  set  of  test  programs  to  validate  a system 
installation.  The  NIPS  360  FFS  system  distributed  on 
magnetic  tape  will  be  in  one  of  the  two  following  formats: 

a.  A dump/restore  which  will  always  be  on  800  BPI,  9- 
track,  SL  tape  labeled  FFS360 

b.  Unloaded  partitioned  and  sequential  data  sets  which 
will  always  be  on  800  BPI,  9-track,  SL  tape  labeled 
FFS360. 

Installations  that  have  2314' s with  the  track  overflow 
feature  will  receive  a dump/restore  tape;  all  other 
installations  will  receive  the  system  as  unloaded 
partitioned  and  sequential  data  sets.  The  dump/restore  tape 
format  will  be  the  normal  mode  of  distribution  of  the 
system. 


3. 1 overview 

The  NIPS  360  *FS  Installation  Package  consists  of: 

a.  Sample  JCL  to  assist  in  creating  the  new  system 
(appendix  C) 

b.  The  NIPS  360  FFS  system  data  sets  in  the  fora  of 
either  a dump/restore  tape  or  unloaded  partitioned 
and  sequential  data  sets 

c.  A library  of  sample  jobs  that  exercise  each 
component  to  ensure  that  the  system  installation 
was  successful 
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d.  A library  of  sanple  subroutines  and  tables  used  by 
the  sanple  jobs  during  system  testing. 

The  library  of  sanple  jobs  and  the  library  of  sanple 
subroutines  and  tables  will  be  distributed  as  systen  data 
sets  and  will  be  included  on  the  systen  tape. 


3.2  Systen  Data  Sets 

NIPS  360  PFS  is  a disk  resident  systen  existing  as  two 
data  sets:  a Program  Library  (FPS.  JOBLIB)  containing 
executable  load  nodules  and  a Macro  Library  (FPS. JOBHACRO) 
containing  nacros  used  when  NIPS  generated  code  is  being 
conpiled.  A Skeleton  File  Library  must  exist  but  can  occupy 
a nininun  amount  of  space  (i.e.,  one  cylinder).  A PTF 
program  library  (PTP. JOBLIB)  and  nacro  library 
(PTF. JOBHACRO)  nust  also  exist,  but  will  not  contain 
executable  load  nodules  or  nacros,  until  progran  transnittal 
fixes  have  been  applied  to  the  systen.  Other  data  sets  are 
included  with  their  purposes  defined. 


3.3  Prog  .-an  Library  - PFS.  JOBLIB 

The  NIPS  360  FPS  executable  load  nodules  (programs)  are 
in  a partitioned  data  set  called  PFS. JOBLIB.  The  members  of 
this  library  are  a result  of  link  editing  the  NIPS  routines 
and  subroutines  into  appropriate  overlay  structures.  The 
NIPS  systen  library  is  referenced  on  the  STEPLIB  DD 
statenent  and  by  the  JOBLIB  synbolic  parameter  in  the  NIPS 
procedures.  The  Program  Library  is  concatenated  to  the 
user's  File  library  and  General  Library  (DUMMY. FILSL)  so 
that  subroutines,  tables,  RITs,  and  retrievals  can  be  stored 
on  this  library  although  they  are  usually  placed  on  a User 
Library.  Depending  on  the  type  of  installation,  this 
library  will  be  received  as  either  an  unloaded  PDS  or  as 
part  of  a dunp/restore  tape  of  the  NIPS  system  disk  pack. 


3.4  Macro  Library  - FPS. JOBHACRO 

The  NIPS  360  PPS  generative  code  nacros  are  in  a 
partitioned  data  set  called  PFS. JOBHACRO.  These  macros  are 
called  during  the  compilation  of  the  generated  code  produced 
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by  the  NIPS  components  and  this  library  must  be  on-line 
whenever  NIPS  batch  jobs  are  being  executed.  Depending  upon 
the  type  of  installation  this  library  will  be  received  as 
either  an  unloaded  PDS  or  as  part  of  the  dump/restore  tape 
of  the  NIPS  system  disk  pack. 


3.5  Procedures  Library  - PFS.PROCLIB 

Each  NIPS  360  PFS  component  is  executed  using  cataloged 
procedures.  These  procedures  use  the  symbolic  parameter 
feature  which  allows  the  user  to  run  most  NIPS  jobs  with  no 
DD  statement  overrides.  Additional  information  regarding 
the  use  of  the  NIPS  procedures  can  be  found  in  the  "NIPS  360 
FFS  Job  Preparation"  manual. 

The  NIPS  360  FFS  procedures  are  set  up  with  the  UNIT 
parameters  specifying  NIPW  for  direct  access  work  space, 
TAPE9  for  9-track  tape,  and  TAPE?  for  7-track  tape.  If 
these  parameters  are  not  recognized  at  an  installation  the 
procedures  will  have  to  be  modified.  For  example,  2314  may 
have  to  be  substituted  for  NIPW. 

Depending  on  the  type  of  installation,  this  library  will 
be  received  as  either  an  unloaded  PDS  or  as  part  of  the 
dump/restore  tape  of  the  NIPS  system  disk  pack.  The  NIPS 
procedures  should  be  moved  into  the  SYS1.PR0CLIB  data  set. 
Any  procedure  modifications  should  be  made  before  the 
procedures  are  moved  to  SYS1.PFOCLIB. 


3.6  Skeleton  File  Library  - DUMMY. PILEL 

NIPS  36C  FFS  reguires  that  a Skeleton  File  Library 
called  DUMMY. FUEL  exist  although  it  can  occupy  a minimum 
amount  of  space  (i.e.  one  cylinder).  The  Skeleton  File 
Library  is  concatenated  to  the  User  Library  so  that 
subroutines,  tables,  RITs  and  retrievals  could  be  maintained 
on  this  library  although  they  are  usually  placed  on  a User 
Library.  In  this  arrangement  the  Skeleton  File  Library 
could  be  utilized  as  a generalized  library.  If  DUMMY. FILEL 
is  to  be  used  as  a generalized  library,  the  user  should  be 
aware  that  NIPS  360  FFS  components  jjiil  fifit  store 
subroutines,  tables,  RITs  and  retrievals  directly  Into  this 
library.  Depending  upon  the  type  of  installation,  this 
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library  will  be  received  as  either  an  unloaded  PDS  or  as 
part  ot  a dump/restore  tape  of  the  NIPS  system  disk  pack. 


3.7  Sample  Jobs  Library  - NIPS. SAMPLE. JOB 

A library  of  sample  jobs  to  test  the  aajor  components  of 
the  NIPS  system  is  a partitioned  data  set  consisting  of  80 
character  card  images.  The  sample  jobs  library  is 
distributed  on  the  system  tape. 

The  sample  job  is  stored  on  NIPS. SAMPLE. JOB  library  and 
consists  of  15  members.  Each  member  contains  card  images 
that  are  the  NIPS  source  statements  for  testing  each  major 
component.  The  test  is  made  up  of  eight  jobs  with  as  many 
as  three  steps  in  one  job.  The  . first  member  of 
NIPS. SAMPLE. JOB  is  ( BLDJCL) . This  member  contains  the  job 
control  language  which  is  necessary  to  execute  each  job. 

The  SYSIN  DD  statement  for  each  job  contains  the  member 
name  of  the  required  scored  source  statements.  These 
members  are:  DTGOS,  SUBLDR,  PCMDS,  BLDTEST,  GENFH,  UPDFH, 

TPTQPSD  TSTOPSD,  TSTPASP,  'TSTOP,  TSTRAQU,  TSTOUIP,  TPLOGPFT, 

TPLOGLS. 

The  following  listing  is  a copy  of  the  Job  Control 
Language  used  in  this  job: 

//SUBTEST  JOB  , ?FS , HSGLEVEL= 1 , PPT Y= 1 2 
//OUTDATE  EXEC  ASMPCL 

//SYSIN  DD  DISP=(SHR, KEEP), U NIT=231 4 , DSN=N IPS. SAMPLE. JOB(DTGOS) 
//LKED.  S YSLMOD  DD  DSN  AH 5=6TEHP (DTGOS)  ,DISP=  (NEN#PASS)  ,UNI?=SYSDA, 
//  SPACE=(CYL, (5,5,200) ) 

//SUBLDF  EXEC  XSUB LDR , LI B=TESTHS 

//SYSIN  DD  D.ISP=  (SHR,  KEEP)  , UNIT=2 31 4, DSN =NI PS. SA MPLE . JOB (SU BLDP) 
//TABGEN  JOB  , PFS  , HSGLE VEL=1 , PRTY= 1 1 
//TAB2  EXEC  XT ABGEN,LIB=TESTER 

//SYSIN  DD  DISP  = (SHR,KEEP) , 0 NIT*2 31 4#DSN*N IPS. S AMPLE. JOB (RCMDS) 

//FPT JOB  JOB  , FFS,MSGLFVEL=1,PR?Y=10 

//FS  EXEC  XPS, ISAM* TESTER, LI B=T ESTER, NDISP=K EE P 

//SYSIN  DD  D IS  P= (SH  R, KEEP)  , UNIT=231 4, DSN  = NIPS. SAMPLE .JOB (BLDTEST) 
//FM  EXEC  XFM,  ISAM* TESTER, LI  8 = TES'"ER,GEN=OVFLON  = 3 
//SYSIN  DD  DISP=  (SHR,  KEEP),  U N IT=2  31  4,  DSN  = NI  PS.  SAMPLE.  JOB(GENPM) 
//UPDT  EXEC  XFMEX , I SAM=TSSTEP , L IB*TESTEP 

//SYSIN  DD  DISP= (SHR, KEEP) , UNIT =2314, DSN=NIPS. SAMPLE. JOB (UPDFH) 
//OUIPSD  JOB  , FFS,MSGLEVEL=1,PPTY=7 
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//QUIPSD  EXEC  XQUIPSD,ISAM=TESTEP,LIB=TESTEP 

//SYSIN  DD  DISP=  (SHR,  KEEP)  , UN IT=2 3 1 4, DSN  = NIPS. S A MPLE . JOB (TSTQPS D) 
//OPS  JOB  ,FFS,  NSGLEVEL=1  , PRTY=6 
//OPSD  EXEC  XOPSD, IS  AM =TESTFR , LI B=TESTER 

//SYSIN  DD  DISP=  (SHR, KEEP)  , UNIT=2 31 4, DSN=NIPS. S AMPLE. JOB (TSTOPSD) 

//BASPOP  JOB  ,?FS,  MSGLEVEL=1,PRTY=5 

//GO  EXEC  XRASP,  ISAM  =T ESTEP,  LI  B=TE S’"' ER,  LI BDISP=OLD 

//SYS IN  DD  DISP= (SHR, KE EP) , U NIT  = 2 31 4, DSN =NIPS . S A MPLE . JOB (TSTPASP) 

//GOGO  EXEC  XOP, ISA M=  TESTER, LI3=TES"I'ER, LI BDISP  = OLD 

//SYSIN  DD  DISP=(SHP,KFEP) , UN IT=2 3 1 4,  DSN  = NI PS. S A MPLE . JOB (TSTOP) 

//RASPQUTP  JOB  ,FFS,HSGLEVEL=1,PPTY=4 

//GO  EXEC  XRASP, ISAH=TESTEP,LIB=7ESTEP 

//SYSIN  DD  DISP=(SHB,KFFP) , UNIT=23 1 4 , DSN=N IPS . S AHPL E. JO B (TSTR AQU ) 
//GOALSC  EXEC  XQUI P, SO URCL=TESTEP , SD ISP=OLD , V SOUPCL= • SE R=FFSLI B* 
//QUIP. SOORCLIB  DD  DS N= TESTE  PL ( QUEH Y1 ) 

//SYSIN  DD  DISP= (SHR, KEEP) , UN IT=2 31 4, DSN=NIPS . S A MPLE. JOB (TSTQU IP ) 
//TPLOGJOB  JOB  , FFS, HSGL5VEL= 1 , PPTY=9 
//FS  EXEC  XPS,ISAM=LOGFILE,NDISP=KEEP 

//SYSIN  DD  DIS P= (SHR, KEEP) , UN IT  = 2 3 1 4, DSN  = NI PS . S A MPLF. JOB (TPLOGFFT) 
//FM  EXEC  XFM, ISAH=LOG?ILE 

//SYSIN  DD  DISP= (SHR, KEEP) ,UNIT=2314, DSN=N IPS . S AMPLE .JOB (TPLOGLS) 

After  the  NIPS. SAMPLE. JOB  library  has  been  restored  .to 
disk,  the  I EBGENER  system  utility  may  be  used  to  punch  the 
member  BLDJCL.  At  this  time  any  required  alterations  to  the 
JCL  may  be  made  by  the  user  to  satisfy  installation  and/or 
system  requirements.  All  SYSIN  DD  statements  in  BLDJCL 
refer  to  a member  on  NIPS . SAMPLE. JOB.  The  user  must  alter 
the  JCL  to  identify  the  volume  serial  number  NIPS. SAMPLE. JOB 
or  catalog  the  library  before  the  test  is  conducted. 

To  perform  the  test  the  user  must  submit  a batch  job 
consisting  of  the  BLDJCL  member. 

The  first  job,  SUBTEST,  will  compile  and  load  a user 
subroutine  (DTGOS)  onto  a file  library  called  TESTEPL.  This 
library  is  supplied  with  the  installation  package  and 
contains  additional  subroutines  and  tables  needed  by  jobs 
which  test  other  components  (OP,  RASP). 

The  next  job  called  FFTJOB  is  a three  step  job  that 
structures  the  FFT  using  File  structuring  component; 
generates  the  file  using  File  Maintenance;  and  updates  the 
file  using  PH.  In  addition  to  adding  data  to  the  file,  the 
PH  step  compiles  logic  statements  and  includes  them  with  the 
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FFT  toe  the  TESTER  file.  (NOTE:  The  INDEX,  PRIME,  and 
OVFLOW  parameters  on  the  execute  card  of  the  FM  step  reflect 
space  considerations  for  a 2314  file.  If  the  TESTER  file  is 
on  a 2311,  the  PRIME  and  OVFLOW  values  need  only  be  tripled 
since  the  original  space  estimates  were  conservative. 
Installations  with  3330  disks  may  decrease  the  space 
allocation  accordingly. 

Parts  ot  the  TESTEP  file  are  then  displayed  by  QUIP  in 
the  QU I PSD  JOB  and  by  the  Output  processor  in  the  OPSD  JOB. 

The  RASPOP  JOB  is  a combination  of  the  Retrieval  and 
Sort  Processor  component  arid  the  Output  Processor  component. 

The  RASPQUIP  job  is  a combination  of  RASP  and  QUIP  in  a 
two  step  job. 

The  final  job  (TPLOGJOB)  is  an  example  of  creating  an 
FFT  and  a logic  statement  which  could  be  used  to  generate 
and  maintain  a file  containing  statistical  data  on  terminal 
usage. 

The  source  statements  for  this  test  were  organized  by 
job  as  individual  members  of  a library  for  the  convenience 
of  the  user.  If  the  user  prefers,  all  of  the  source 
statements  may  be  output  in  punched  card  form  and  entered 
into  the  job  stream  via  the  card  reader.  The  number  of 
source  statements  required  is  in  excess  of  3400  punched 
cards. 


3.8  Sample  Subroutine  Library  - TESTERL 

A partitioned  data  set  named  TESTERL  contains 
subroutines  and  tables  used  by  the  sample  jobs.  This  data 
set  must  exist  and  be  cataloged  to  run  sample  jobs  but  it 
can  be  scratched  once  the  NIPS  360  FFS  has  been 
satisfactorily  tested.  This  data  set  will  be  sent  as  either 
an  unloaded  PDS  or  as  part  of  a dump/  restore  tape  of  the 
NIPS  system  disk  pack. 
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3.9  blocksize  Considerations 

The  system  data  sets  are  distributed  with  the  space  and 
blocksize  paraaeters  specified  in  appendix  D.  NIPS  360  FFS 
procedures  concatenate  the  SYSl.nACLIB  to  FPS. JOBFACRO.  In 
order  to  satisfy  concatenation  requirements  of  the  Operating 
Systea,  the  blocksize  of  FFS.JOBHACRO  must  be  greater  than 
or  equal  to  the  blocksize  of  SYSl.nACLIB.  Therefore, 
depending  upon  the  blocksize  of  SYSl.nACLIB,  the  blocksize 
of  the  FFS. JOBHACRO  data  set  nay  have  to  be  increased. 
Likewise,  the  NIPS  360  FFS  procedures  concatenate  User 
Subroutine  Libraries  with  the  SLIB  DD  statement  such  that 
FFS. JOBLIB  is  concatenated  to  a data  set  having  the  DCB 
attributes  of  SYS1. LINKLIB.  This  requires  that  FFS. JOBLIB 
have  a blocksize  equal  to  or  less  than  the  block  size  of 
SYS1 .LINKLIB. 
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Section  4 

INSTALLATION  PROCEDURES 


To  initialize  NIPS  360  FFS,  four  principal  functions 
■ust  be  performed  using  S/360  utilities.  These  functions 
are  to: 

a.  Catalog  the  data  sets  required  by  the  system 

b.  Restore  the  system  data  sets  to  a direct  access 
device 

c.  Move  the  NIPS  360  FPS  procedures  (FPS . PROCLIB)  to 
the  System  Procedures  Library  - SIS1.  PROCLIB 

d.  Run  the  sample  jobs  to  ensure  a successful  system 
installation. 

Each  function  is  discussed  in  the  following  paragraphs.  An 
illustrative  procedure  for  installing  the  NIPS  360  FFS  at  a 
computer  facility  with  IBM  2314  disk  units  is  provided  in 
appendix  B.  This  typical  procedure  shows  the  type  of  JCL 
required  by  the  S/360  utilities  to  perform  the  functions 
described  below. 

The  first  function  in  initializing  the  system  is  to 
catalog  the  following  system  data  sets:  FFS..JOBLIB, 
FFS. JOBHACRO,  FFS. PROCLIB,  PTF.JOBLIB,  PTF. JOBMACRO, 
TESTERL,  DUMMY. FILE,  DUMMY. FILEL,  DUMMY. FILEY,  and 
DUMMY. FILES.  The  last  four  data  sets  are  required  as 
"default"  data  sets  by  the  NIPS  procedures.  DUMMY. FILES  and 
DUMMY. FILEY  should  be  cataloged  to  the  NIPS  system  pack 
since  they  are  never  actually  called  for  by  the  system. 

The  second  function  is  to  restore  the  system  data  sets 
required  by  NIPS  360  FFS  to  disk.  If  the  system  was 
received  as  a dump/restore  tape,  reload  the  system  data  sets 
to  a direct  access  device  by  using  the  IEHDASDR  Utility 
program.  If  the  system  data  sets  were  received  as  unloaded 
partitioned  and  sequential  data  sets,  restore  then  to  disk 
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by  first  allocating  space  for  them  and  then  reloading  them 
from  tape. 

The  third  function  in  the  initialization  of  the  NIPS  360 
FPS  is  putting  the  procedures  into  the  S YS1 . PFOCLI B.  The 
procedures  are  sent  as  members  of  the  partitioned  data  set 
named  FFS.PROCLIB.  The  procedures  can  be  punched  from  this 
data  set  with  the  Utility  Program  IEBPTPCH.  They  can  then 
be  modified  if  necessary  or  placed  directly  into  the 
SYS1.PROCLIB  with  the  IEBUPDTE  Utility  program.  If  punched 
procedures  are  not  desired,  the  "REPFO"  capability  of  the 
IEBUPDTE  program  can  be  used  to  update  the  S YS 1 . PROCLIB. 

The  final  function  is  to  run  the  sample  jobs  to  test  the 
system  installation.  The  sample  jobs  are  on  a seguential 
data  set  named  NIPS. SAMPLE. JOB  as  unblocked  card  images. 
The  sample  jobs  can  be  punched  and  submitted  via  the  card 
reader  or  copied  to  tape  and  loaded  directly  from  the 
operator's  console  (SYSIN  tape).  If  an  installation 
requires  specific  accounting  information,  the  job  cards  for 
all  of  the  sample  jobs  will  have  to  be  changed.  (See 
appendix  b. ) 
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Section  5 
UPDATES 


NIPS  360  FPS  will  be  maintained  at  a user’s  installation 
by  means  of  version  updates  and  Program  Transmittal  ’’ixes 
(PTF).  Version  updates  will  be  done  infrequently  and 
correspond  to  a major  system  change. 


5.1  Version  Changes 

NIPS  360  FPS  received  in  an  installation  package  will 
have  a 4-digit  version  number  associated  with  it.  This 
version  number  corresponds  to  a major  system  upgrade  and  is 
the  version  number  referred  to  in  a Discrepancy  Change 
Report  (DCR).  A version  update  will  usually  involve  an 
upgrade  of  the  load  modules  for  an  entire  component  (s)  and 
will  not  occur  very  often.  It  will  require  replacing  the 
PFS. JOriLI B and/or  FPS.JOBMACRO  system  data  sets.  Version 
updates  will  include  all  prior  PTFs;  therefore,  system  data 
sets  PTF.JOBLIB  and  PTF.JOBMACPO  will  be  replaced  with  new 
data  sets  initialized  for  future  PTFs. 


t 

i 


I 


; 


5.2  Program  Transmittal  Fix  (PTF) 

NIPS  360  FFS  may  be  updated  by  applying  PTFs  to  a given 
version  of  the  system.  PTFs  will  be  received  by  an 
installation  as  one  or  more  jobs  that  are  processed  by  the 
Operating  System  like  any  other  batch  job.  When  executed, 
these  PTF's  will  perform  the  update  of  the  specific  part  of 
NIPS  360  FFS  that  is  to  be  upgraded. 

Each  PTF  will  have  a 2-digit  number  associated  with  it. 
The  job  card  of  each  PTF  will  have  a job  name  in  the  form  - 

//Vnnnnppt  JOB  , , HSGLEVEL=1 
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V 


where 


nnnn  = OS  release  number/NIPS  version  number 
pp  = Two-digit  PTP  number 

t * S,  update  to  Program  Load  Library  (FFS.JOBLIB) 

M,  update  to  Macro  Library  (FFS. JOBHACRO) 

P,  update  to  NIPS  procedures  (SYS  1.PR0CLIB) 

A PTP  number  will  be  written  across  the  top  of  each  PTF  job 
dec*.  PTFs  which  update  the  Program  Load  Library  will 
specify  a procedure  named  XPFSPTFL  on  the  EXEC  card.  This 
procedure  has  been  moved  onto  SYSl.PROCLIB  along  with  the 
other  NIPS  procedures. 


Note:  Updates  to 

on  PTF.JOBLIB 


FFS.JOBLIB  and  FFS.JOBMACRO  will 
and  PTF. JOBMACPO  respectively. 


be  placed 


?■ 
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Section  6 

DISCREPANCIES  AND  CHANGES 


NIPS  360  FFS  is  considered  to  be  a dynamic  system  which 
is  constantly  being  improved  and  expanded.  As  such,  it  is 
unlikely  that  it  will  ever  reach  a final  version.  This 
section  describes  how  system  users  should  notify  the  Command 
and  Control  Technical  Center  (CCTC)  of  system  discrepancies 
and  now  they  can  suggest  changes  and/or  additional 
capabilities. 

The  vehicle  for  reporting  a discrepancy  or  change  is  the 
Discrepancy/Change  Report  (DCP) . A copy  of  the  DCR  is 
included  in  appendix  E.  This  DCP  should  be  sent  to: 

Director 

Command  and  Control  Technical  Center 
The  Pentagon,  Room  BE685 
ATTN:  C333  NIPS  Project  Officer 
Washington,  D.C.  20301 


When  a discrepancy  is  suspected  in  the  NIPS  360  PFS, 
gather  all  data  on  the  run,  and  submit  it  on  a DCR.  The 
only  required  information  on  a DCR,  in  addition  to  the 
submitter's  name  and  address,  is  the  system  version  number 
for  the  NIPS  360  PFS  system  in  use.  The  most  important 
portion  of  the  report  is  the  submitter's  description  of  the 
problem.  In  this  section,  the  user  should  describe  the 
problem  in  as  much  detail  as  necessary  to  assist  in 
effecting  a solution.  The  remainder  of  the  DCR  entries  are 
optional  depending  on  the  type  of  discrepancy  or  change 
being  reported. 


As  soon  as  the  DCR  is  received  by  CCTC  a priority  is 
assigned  by  the  NIPS  Technical  Support  Group  and  the 
Contracting  Officer  Representative  (COR),  and  an  entry 
containing  pertinent  information  on  the  DCR  is  created  in 
the  consolidated  file  of  outstanding  DCRs.  At  predetermined 
times,  all  DCRs  for  a particular  component  are  evaluated  by 
the  NIPS  Technical  Support  Group  and  the  COR  to  prepare  a 
list  of  DCRs  to  be  scheduled  for  analysis  and  resolution. 
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Once  a DCR  has  been  activated,  a maintenance  programmer  may 
request  additional  information  from  the  submitter.  When  the 
problem  has  been  fixed  and  tested,  the  solution  is  recorded 
on  a Maintenance  Programmer's  Report  (see  appendix  F)  . At 
this  point,  a Program  Transmittal  Fix  (PTF)  has  been  created 
and  may  be  mailed  to  the  originator  depending  on  the 
severity  of  the  problem.  Applying  this  PTF  to  the  user's 
system  will  resolve  the  problem  until  the  next  scheduled 
version  of  NIPS  360  FFS  is  released. 


6. 1 Reporting  Discrepancies 

This  discussion  of  system  discrepancies  is  limited  to 
three  types.  These  are  system  abnormal  termination,  failure 
of  the  system  to  function  properly,  and  errors  in 
documentation.  These  types  of  errors  should  be  reported  to 
the  CCTC  so  that  appropriate  action  can  be  taken.  It  is 
expected  that  each  user  installation  will  have  system 
maintenance  personnel  available  to  distinguish  system 
problems  from  environmental  and  utilization  problems. 

System  abnormal  termination  is  the  easiest  discrepancy 
for  the  user  to  identify  since  it  is  usually  followed  by  an 
ABEND  dump.  In  the  procedures  included  with  the 
installation  package,  a SYSUDUMP  is  normally  specified. 
When  a dump  is  taken  by  the  NIPS  360  FFS  programs,  it  should 
always  be  included  with  the  DCR  unless  security 
considerations  do  not  allow.  In  this  case,  the  job  should 
be  recreated  with  an  unclassified  file. 

In  addition  to  the  ABEND  dump,  the  DCF  describing  an 
abnormal  termination  should  include  the  significant  portion 
of  the  job's  input  stream.  The  complete  JCL  should  be 
listed  and  also  the  data  when  it  is  germane  to  the  problem. 
The  listing  of  the  JCL  can  be  obtained  via  the  MSGLEVFL 
parameter  on  the  JOB  card. 

Discrepancies  of  the  type  where  the  system  fails  to 
function  properly  but  does  not  end  with  an  abnormal 
termination  are  more  difficult  to  diagnose.  In  these  cases, 
the  accurate  description  of  the  problem  on  the  DCR  is 
critical.  In  addition,  as  much  information  as  possible 
concerning  the  problem,  should  be  sent  with  the  DCR.  As  a 
minimum,  the  input,  output,  and  JCL  for  the  job  should  be 
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included;  when  a file  is  involved  in  the  problem,  a listing 
of  the  FFT  should  be  sent. 

The  third  type  of  discrepancy  may  have  nothing  to  do 
with  the  successful  operation  of  the  NIPS  360  FPS  programs, 
but  errors  in  the  documentation  can  be  considered  system 
discrepancies  in  the  broader  sense.  In  reporting 
documentation  errors,  it  is  important  that  the  document  in 
question  be  properly  identified.  The  document 
identification  should  include  the  document  name,  document  ID 
number,  volume  number,  page,  and  change  number,  if 
applicable. 

It  is  expected  that  most  DCRs  concerning  documentation 
errors  will  refer  to  technical  discrepancies  or  deficiencies 
instead  of  typographical  errors.  The  discrepancy  should  be 
described  in  the  DCF  and  a recommended  solution  to  the  error 
should  be  included. 


6.2  Suggesting  Changes 

The  DCR  may  be  used  to  suggest  changes  to  NIPS  360  FFS 
as  well  as  report  discrepancies.  Changes  suggested  by 
system  users  will  be  considered  as  to  their  overall  effect 
upon  NIPS  360  FFS.  Those  changes  that  enhance  the 
ef tecti veness  of  the  system  and  do  not  conflict  with 
previously  planned  modifications  or  the  overall  system 
design  will  be  considered  for  inclusion.  Scheduling  of 
changes  will  be  based  on  the  amount  of  programming  effort 
required  and  the  availability  of  development  funds. 

In  submitting  changes,  system  users  should  specify  the 
requirements  in  as  much  detail  as  possible  on  the  DCR.  The 
evaluation  of  the  proposed  change  by  the  CCTC  will  be 
significantly  enhanced  by  the  amount  of  detail  provided. 
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Section  7 

TERMINAL  PROCESSING  COMPONENT 


The  Terminal  Processing  (TP)  component  is  a generalized 
TP  Monitor  and  Supervisor  designed  to  support  many  different 
configurations  of  remote  or  locally  attached  terminals.  The 
component  presently  supports  local  2250,  local  or  remote 
2260,  remote  dial-up  (switched  network)  1050,  and  remote 
2741  (nonswitched)  terminals,  and  local  or  remote  3270 
terminals.  This  component  will  allow  remote  jobs  to  be 
executed  from  display  terminals  while  batch  jobs  are  being 
executed . 


7. 1 TP  Space  Considerations 

TP  support  is  available  under  the  MPT-II  and  MVT 
configuration  of  OS/360  and  VS/370.  NIPS  TP  has  three  major 
programs  - a TP  Monitor  (TFHON)  , a TP  Supervisor  (TPSUP)  and 
a TP  Driver  program (UTTPDPV R) . UTTPDRVP  is  used  to  initiate 
the  NIPS  TP  Monitor  and  TP  Supervisor  and  have  them  execute 
within  a single  region/partition  of  core. 

The  core  requirements  for  a single  region  TP  system 
equal  the  sum  of  the  core  required  for  the  TP  Driver,  the  TP 
Monitor,  the  TP  Supervisor,  and  application  programs 
executed  under  the  control  of  the  TP  Supervisor. 

The  TP  Driver  program  requires  1.44k  bytes  of  core. 
Core  requirements  for  TP  Monitor  are  discussed  in  section 
7.1.1.  Section  7.1.2  discusses  TP  Supervisor  core 
requirements. 


INSTALLATION 


7.1.1  TP  Monitor 

TPMON  size  will  vary  depending  on  terminal  configuration 
and  requirements  for  renote  and/or  local  support.  TPMON 
size  nay  be  estinated  for  a specific  installation  using  the 
information  listed  below.  Approximate  sizes  are  as  follows: 

23K  Basic  Monitor 

2.4K  Local  Graphics  Support  [subtract  IK  if  only 

2260's  ] 

[subtract  . 3K  if  only 
2250's  ] 

4.1k  Remote  Support  [subtract  IK  if  there  is  only 

one  terminal  type] 

2.2K  BDAM  - Required  by  Basic  Monitor 

4.5K  GAM  - Required  for  Local  Support 

5.6K  BTAM  - Required  for  Remote  or  3270  Terminal 

Support 

2.2K  BSAM  - Required  for  recording  Accounting  Data 

(optional) 

In  addition,  TPMON  requires: 

a.  150  bytes  for  each  serviceable  terminal 

b.  2K  for  control  blocks 

c.  IK  for  each  remote  communications  line. 


d.  IK  if  the  full  page  buffer  option  is  used 

e.  3.5K  for  the  TPPAGE  program. 

f.  An  additional  amount  for  each  terminal 

if  the  incore  IMQ  option  has  been  specified. 
Eighty  bytes  per  IMQ  line  is  reguired 
for  each  terminal.  Thus,  if  IHQ=25  were 
specified  and  the  monitor  were  generated 
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for  two  terminals,  4K  bytes  would  be 
required. 

All  installations  will  require  the  basic  Monitor,  the  TPPfcGE 
proqram,  BD  AM  access  method,  and  at  least  part  of  the  local 
or  remote  support  group  together  with  the  necessary  access 
method. 
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7.1.2  TP  Supervisor 

The  TP  Supervisor  (TPSllP)  requires  approximately  10K  of 
core.  However,  the  primary  function  of  TPSUP  is  to  control 

the  execution  of  the  TP  applications  programs.  Therefore, 

the  core  requirements  of  the  TP  applications  programs 
comprise  the  most  dynamic  portion  of  the  total  NIPS  TP  core 
requirements.  Absolute  core  requirements  cannot  be  defined 
for  the  NIPS  QUIP  and  SODA  applications.  These  requirements 
depend  on  such  factors  as: 

o The  number  of  terminals  in  concurrent  operation. 

o Processing  block  size.  The  QUIP  process  block  must 
be  larqe  enough  to  contain  the  largest  record  in 
the  file  being  processed.  The  process  block  size 
for  QUIP  is  computed  from  the  file's  statistics 

record  (N  record)  to  permit  processing  of  the 

largest  data  record  in  the  file.  An  N record  is 
always  present  for  an  ISAM  file.  The  default 
process  block  size  for  a SAM  file  without  a 
statistics  record  is  10K.  The  SODA  process  block 
size  must  be  large  enough  to  hold  the  fixed  set 
plus  all  referenced  sets  of  the  data  record. 

o Buffers.  QUIP  and  SODA  both  require  two  I/O 

buffers.  Each  buffer  must  be  large  enough  to 

contain  one  block  of  data  (as  determined  by  the 
data  file  blocksize). 

o The  size  of  user  tables  and  subroutines. 

o The  size  of  the  user  written  application  (i.e., 

query  or  logic  statement) 
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o Concurrent  operation  of  different  TP  application 
programs  (e.g.,  QUIP  and  SODA). 

o Core  f ragaentation  and  work  areas.  Free  core  is 
not  always  available  in  contiguous  areas  in  core. 
Therefore,  a 5K  core  requirement  cannot  be 
satisfied  by  OS  if  there  are  only  4K  contiguous 
areas  of  free  core  remaining  in  the  user's 
region/partition.  Core  fragmentation  will  have  a 
greater  impact  in  a multi  terminal  environment  than 
for  a single  terminal,  since  core  allocation  will 
tend  to  be  more  complex,  with  multiple  applications 
seeking  and  freeing  core.  A limited  amount  of 
temporary  work  space  must  also  be  allocated  from 
the  free  core  area. 

o Use  of  the  INCORFFT  option  for  the  QUIP  component. 
This  option  allows  QUIP  to  maintain  control  and  FFT 
information  in  core  storage  for  files  processed 
while  QUIP  is  in  signon  mode.  Each  field/group  of 
an  FFT  that  is  maintained  in  core  reguires  33 
bytes.  In  addition,  the  statistics  (N)  record  is 
also  maintained  in  core.  QUIP  itself  requires  an 
additional  3K  bytes  for  its  programs  which  maintain 
the  FFTs  in  core. 

o The  load  module  structure  chosen  for  the  QUIP 
component.  Two  load  module  structures  are 
available  for  QUIP:  TPQUIP  and  TPQUIPVS.  The 
Monitor  and  Supervisor  are  distributed  to  use  the 
TPQUIP  structure.  (See  Section  7.15,  TPQUIPVS  Load 
Structure  for  QUIP.) 

Estimated  core  requirements  for  the  first  seven  of  the 
above  factors  can  be  obtained  by  executing  a typical 
application  in  the  associated  batch  component  (i.e.,  QUIP, 
FM),  and  using  the  option  to  generate  Run  Optimization 
Statistics  (ROS).  ROS  will  produce  statistics  for  the 
following  core  requirements: 

Component 

Buffers 

Process  block 

Tables  and  subroutines 

User  written  applications. 


23 


INSTALLATION 


The  effect  of  the  above  factors  on  TP  core  requirements 
will  be  discussed  first  in  a single  terminal  environment, 
and  then  in  a multiterminal  environment. 


7. 1.2. 1 TP  Supervisor  for  Single  Terminal 

For  purposes  of  illustration,  a sample  environment  will 
be  defined  as  follows: 

o Size  of  largest  data  record  - 5K 
o File  blocksize  - 7k 
o User  tables  and  subroutines  - 6K 
o Size  of  user  logic  statement  - 2K 

o Size  of  user  query  - 3K 

The  TPSUP  core  requirements  to  support  a single  terminal  for 
QUIP  can  be  estimated  as  follows: 


Supervisor  10K 

QUIP  component  (TPQUIP  load  structure)  56K 

QUIP  component  (TPQUIPVS  load  structure)  104k 

♦Processing  block (size  of  largest  record)  5K 

♦User  tables  and  subroutines  6K 

♦ Buffers  (2  buffers  x 7K)  14K 

♦User  query  3K 

♦Total  estimated  core  (TPQUIP 

load  structure)  90K 

♦T'otal  estimated  core  (TPQUIP?S 

load  structure)  138K 


♦Based  on  sample  environment 

The  core  requirements  to  support  a single  terminal 
for  SODA  can  be  estimated  as  follows: 


Supervisor  10K 

SODA  component  40K 

♦Processing  block  5K 

♦User  tables  and  subroutines  6K 

♦Buffers  (2  buffers  x 7K)  14K 
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♦Logic  Statements  2K 

♦Total  estimated  core  73K 


♦Based  on  sample  environment 

The  core  requirements  for  EDIT  are  not  affected  by  the 
number  of  terminals  or  the  user  application.  The  estimated 
core  requirements  for  EDIT  are  as  follows: 


Supervisor  10K 

EDIT  (without  VERIFY)  16K 

EDIT  (with  VERIFY)  116K 

A user  executing  both  SODA  and  QUIP  from  a single 
terminal  can  normally  plan  on  running  in  a region/partition 
size  which  supports  the  larger  of  these  two  applications. 
The  user  must  terminate  QUIP  before  initiating  SODA  from  the 
same  terminal.  It  is  possible  however,  to  initiate  QUIP 
without  signing  off  from  SODA.  SODA  is  terminated  by 
issuing  an  UPDATE  or  CANCEL  command.  If  the  user  attempts 
to  issue  a QUIP  query  without  properly  terminating  SODA,  the 
Supervisor  will  require  core  for  both  QUIP  and  SODA. 

A user  can  initiate  either  QUIP  or  SODA  from  a terminal 
while  being  signed  on  to  EDIT.  Therefore,  the  core 
requirements  for  EDIT  must  be  added  to  the  core  requirements 
for  QUIP  or  SODA  to  run  EDIT  concurrently  with  those 
applications. 


7. 1.2. 2 TP  Supervisor  for  Multiple  Terminals 

The  core  requirements  to  support  multiple  terminals 
depend  on  the  number  of  concurrent  TP  applications  which  are 
anticipated.  Terminals  entering  data  on  the  Input  Message 
Queue  (IMQ)  or  paging  through  data  on  the  Output  Message 
Queue  (ONQ)  do  not  affect  TPSUP  core  requirements. 

A single  copy  of  QUIP,  SODA,  or  EDIT  will  support  any 
number  of  terminals.  However,  each  active  QUIP  (i.e.,  in 
query  translation  or  file  search)  or  SODA  (transaction 
processing)  terminal  will  require  additional  core  for: 
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Processing  block 
Buffers 

Tables  and  subroutines 
User  written  application 
Data  control  blocks 

File  locate  and  read  programs,  (nonreentrant) 
Internal  table  and  work  areas. 

As  an  example,  assume  the  following  multiterminal 
environment : 

o Ten  terminals 

o Three  terminals  active  using  QUIP 
o Two  terminals  active  using  SODA 
o Two  terminals  active  using  EDIT 
o Size  of  largest  data  record  - 5K 
o Pile  blocksize  - 7k 
o User  tables  and  subroutines  - 6K 

o Size  of  user  logic  statements  - 2K 

o Size  of  user  gueries  - 3K 

The  TPSUP  core  requirements  to  support  the  above  sample 

TP  environment  can  be  estimated  as  follows: 


Supervisor  10K 

QUIP  component  (TPQUIP  load  structure)  96K 

QUIP  component  (TPQUIPVS  load  structure)  178K 

♦QUIP  processing  blocks  (3)  15K 

♦QUIP  tables  and  subroutines  (3)  18K 

♦QUIP  buffers  (6)  42K 

♦QUIP  user  queries  (3)  9K 

SODA  component  40K 

♦SODA  processing  blocks  (2)  10K 

♦SODA  tables  6 subroutines  (2)  12K 

♦SODA  buffers  (4)  28K 

♦SODA  logic  statements  (2)  4K 

EDIT  (with  VERIFY)  116K** 

♦Total  estimated  core (TPQUIP  load  structure)  400K 


♦Total  estimated  core  (TPQUIPVS  load  structure)  482K 

♦Based  on  sample  environment 

♦♦Without  VERIFY  - subtract  100K  if  VERIFY  will  not  be  used  in 
EDIT. 
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7.2  TP  Installation 

The  TP  component  requires  the  following  additional 
installation  procedures  to  include  it  as  part  of  NIPS  360 
FFS: 


a.  Update  SYS1.5VCLIB  - A Type  III  SVC  module  must  be 
added  “to”  the  SYS1.SVCLIB  if  NIPS  ’’•p  is  to  be  run 
and  the  operating  environment  is  S/360  or  S/370  VSl 
or  S/370  VS2  Release  1.  The  TP  SVC  is  not  required 
in  an  MVS  environment.  Generation  of  the  TP  SVC 
involves  specifying  options  on  the  QTPSVCGN  macro, 
assigning  a valid  Type-Ill  SVC  number  and  executing 
the  TPSVCUPD  job.  The  SVC  number  chosen  has  the 
following  implications.  The  TPMON,  as  distributed, 
is  generated  to  use  a Type-Ill  SVC  number  240.  If 
your  SYSGEN  defines  SVC  240  as  a Type-III  user  SVC 
and  it  is  not  being  used,  put  this  number  in  the 
space  provided  for  it  (IGC00NNN)  . If  your  system 
does  not  define  240  as  a Type-III  user  SVC,  or  if 
this  SVC  has  already  been  used,  check  to  see  if 
another  Type-III  SVC  number  is  available.  If  no 
Type-III  SVC  numbers  are  available,  the  Operating 
System  must  be  SYSGEN'ed  to  provide  one.  If  one 
exists,  place  this  number  in  the  space  provided. 
If  an  SVC  number  other  than  240  is  used  TPMON  will 
have  to  be  modified  to  reflect  this  new  SVC  number 
(see  TP  Monitor  Generation) . After  the  SVC  has 
been  added  to  the  SVC  library  and  before  attempting 
to  execute  NIPS/TP,  the  Operating  System  should  be 
re-IPLed. 

Specification  of  the  TPSVC  options  is  done  by  using 
the  QTPSVCGN  macro  in  the  following  format: 

QTPSVCGN  GAM2250=NO,CP67=NO 

YES  YES 

where: 

GAM2250=NO 

YES 

The  GAM2250  option  defaults  to  NO 
which  indicates  that  no  2250  device 
will  be  released  by  NIPS/TP,  during 
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its  execution,  to  an  independent 
graphics  progran.  YES  should  be 
specified  only  in  environments  where 
2250  devices  are  supported  by  TP 
Monitor,  and  are  going  to  be 
referenced  by  independent  graphics 
packages 

CPb  7 = N0 
YES 

The  CP67  option  defaults  to  NO  which 
indicates  that  the  run  environment 
is  not  a CP67.  YES  should  be 
specified  if  the  operating 
environment  is  a CP67  and  the  need 
for  DIALing  real  terminals  to 
virtual  port  addresses  exists. 

Error  conditions  produced  during  the  TPSVC 
generation  are  described  in  section  7<10  of  this 
document. 

NOTE:  If  the  TP  SVC  is  required,  it  is  necessary  to 
execute  the  TPSVCHPD  job  even  if  all  the  default 
values  in  the  QTPSVCGN  macro  are  taken.  This  is 
because  two  functions  required  by  NIPS/TP  must  be 
executed  in  OS  Supervisor  state. 

The  following  is  a sample  deck  for  generating  the 
TPSVC. 


//TPSVCUPD 

// 

// 

//ASH. SYSLIB 
// 

//ASH.SYSIN 


JOB 

EXEC  ASHFCL,PABH. ASH* ( LOAD, NODECK) , 
RH.LKED*HAP 
DD 

DD  DISP=SHR,DSN*7FS. JOBHACPO 
DD  * 

QTPSVCGN 

END 

//LKED. SYSLHOD  DD  DSN=S YSl .S  VCLI B (IGCObNNN) , DISP=OLD 


The  QTPSVCGN  macro  statement,  with  all  the  default 
values  taken,  will  result  in  the  TPSVC  being 
generated  with  the  two  basic  functions. 
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The  last  card  in  the  TPSVCUP  job  applies  to  the 
liokedit  step  of  the  ASNFCL  procedure.  The  DSNAHE 
parameter  on  the  SYSLHOD  card  points  to  SYSl.SVCLIB 
which  is  to  contain  the  generated  SVC.  The  value 
in  parenthesis  is  the  SVC  name  - IGCOONNN.  The 
proper  SVC  number  iust  be  given.  It  is  important 
to  note  that  Type-III  SVC  numbers  aust  have  a zone 
(12)  punch  over  the  low-order  digit.  If  the  SVC 
nuaber  is  240,  the  low-order  digit  must  be  a 12-0 
punch. 

b.  UlQ£ate_Ifl£Ut^0at£Vil_DisJi-2Sieae_S£ace  - 

o Input  Queue  - TPMON  requires  an  input  disk 
queue  data  set  if  the  incore  IHQ  option  is  not 
selected  (see  section  7.4,  TP  Monitor 
Generation,  paragraph  a.  Selecting  TP  Monitor 
Options) . 

This  data  set  is  created  and  cataloged  by 
executing  the  TPQ  job  provided  in  appendix  A. 
This  job  will  provide  a queue  space  sufficient 
for  50  input  lines  froa  each  of  10  terminals 
on  a 2314  disk  pack  labeled  FFSLIB. 

If  aore  than  10  terainals  are  being  used  at  an 
installation,  change  the  space  requirement  on 
the  DD1  DD  statement  for  the  TPQ  job  to 
SPACE= (80, X)  where: 

X * 1*(50  * total  number  of  terminals) 

If  the  TPIMQ  data  set  is  not  required,  i.e., 
an  incore  IMQ  has  been  specified,  remove  the 
DD1  data  definition  statement  in  the  TPQ  job. 

o Output  Queue  - TPMON  requires  an  output  data 
set  for  each  terminal  in  the  system. 

They  aust  be  permanent  data  sets  but  not 
cataloged.  All  output  queue  names  take  the 
form  T.terajpalname.  The  default  data  set 
names  for  the  2250  output  queues  are 
T.DD52250A  and  T.D512250A.  Those  for  local 
2260s  are  called  T.DD62260A,  T.DD62260B, 
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...ate.  *or  remote  terminals,  the  terminal 
name  following  the  'T.'  must  be  supplied  by 
the  user.  This  name  must  correspond  to  the 
unique  terminal  name  appearing  in  the  polling 
list  (see  TP  Monitor  Generation  - QTPLINE 
macro) . The  TPQ  job  provided  in  appendix  A 
will  create  two  2250  output  data  sets  and 
eight  local  2260  output  data  sets  on  a disk 
pack  labeled  FFSLIB.  Fewer  Output  Message 
Queues  can  be  created  by  removing  the 
appropriate  number  of  DD  statements  from  the 
back  of  the  deck.  Additional  message  queues 
are  provided  by  adding  more  DD  statements  to 
the  back  of  the  deck,  following  the  naming 
conventions  described  above. 

o EDIT  Queue  - An  alternate  output  queue  is 
required  when  the  EDIT  component  is  used. 

All  attributes  of  this  queue  are  identical  to 
the  Output  Queue  except  the  prefix  character 
of  the  data  set  name.  For  EDIT  queues,  this 
character  is  E (i.e.,  E.DD52250A) . 

Important:  If  TPIMQ  is  allocated,  the  Output 

Message  Queues  must  be  created  on  the  same  disk 
pack  as  the  Input  Message  Queue  (TPIMQ)  since  this 
is  assumed  in  the  TP  Job  Control  Language.  If  an 
incore  IHQ  is  used,  the  volume  serial  number  of  the 
disk  pack  containing  the  Output  Message  Queues  must 
be  specified  on  the  OHSGQ  DD  statement  in  the  TP 
Job  Control  Language. 

Note:  Terminals  named  using  the  naming  option  (see 

TP  Monitor  Generation)  require  output  queues  with 
corresponding  names;  e.g.,  ’ T. USERNAME ' . 

c.  Qfreck  the  TP  Monitgc  - TPNON,  as  distributed,  will 
support  zero,  one  or  two  2250-1  (types  1,  2,  or  3) 
and  zero  to  eight  2260-1s,  all  locally  attached. 
If  the  installation  has  a greater  number  of  either 
terminal  type,  but  only  wishes  to  assign  terminals 
within  the  limitations  indicated  above,  the 
distributed  TPHON  may  still  be  used.  This  Monitor 
will  process  QUIP  (TPQUIP  load  structure) , FMSODA , 
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DUMP,  EDIT,  COEDIT,  BLAST,  ACCESS,  RECOPD,  VIEW, 
ODE  and  independent  graphics  routines. 

If  TPMON  has  to  be  modified  for  (1)  a different  SVC 
number  (or  no  SVC  is  required),  (2)  a greater 
number  of  terminals,  (3)  assigning  names  to 
terminals,  (4)  generating  remote  support,  (5)  an 
incore  IMQ  or  (6)  use  of  the  TPQUIPVS  load 
structure  for  QUIP  (see  Section  7.15,  TPQUIPVS  Load 
Structure  for  QUIP),  read  the  TP  Monitor  Generation 
section  before  proceeding  to  subparagraph  d. 

d.  check  the  TP  Supervisor  - ’’’PSUP,  as  distributed, 
contains  a program  name  table  allowing  operation  of 
the  following  problem  programs:  TPDUMP,  TPLIST1, 
GGINTFAC,  TPQUIP  (TPQUIP  load  structure),  TPPMSODA, 
TPEDIT , TPCOEDIT,  TPBLAST,  TPACCESS,  TPVIEW,  and 
TPODE.  Three  empty  (extra)  entries  are  also 
included  in  the  program  name  table,  for  addition  of 
user  programs  at  execution  time. 

If  TPSUP  has  to  be  modified  for  (1)  adding  or 
deleting  specific  programs  from  the  program  entries 
in  the  program  name  table,  (2)  changing  the  number 
of  empty  entries  in  the  program  name  table,  (3) 
specifying  dynamic  mounting  of  user  disk  packs,  (4) 
specifying  a "lockout"  of  other  program  requests 
when  a Sign-on  program  is  signed  on,  (5)  specifying 
an  MVS  environment  or  (6)  use  of  the  TPQUIPVS  load 
structure  for  QUIP  (see  Section  7.15,  TPQUIPVS  Load 
Structure  for  QUIP),  read  the  TP  Supervisor 
Generation  section  before  proceeding  to 
subparagraph  e. 

e.  Catalog  _ t he  Default  _Data  _Fi],e  - QUIP  will 
dynamically  mount  files  only  so  long  as  the  DSNAME 
field  of  the  DATAFILE  DD  card  (for  ISAM  files)  or 
SAMFILE  DD  card  (for  SAM  files)  contains  the  name 
of  a data  set  of  the  form  DUMMY. name  (e.g., 
DUMMY.  ISA  MFILE)  . The  data  set(s)  do  not  have  to 
exist.  They  must  be  cataloged. 

f-  ai4ti_m2N_aad_IPSUP  - The  TP  component  requires 

two  tasks  called  TPMON  and  TPSUP.  The  UTTPDPVP 
routine  is  executed  to  initiate  the  monitor  and 
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supervisor  and  to  have  then  execute  in  a single 
region  or  partition. 

There  is  one  NIPS  360  F FS  procedure  for  starting  the 
distributed  Monitor  and  Supervisor.  A detailed  discussion 
of  this  procedure  is  found  in  the  TP  Procedures  section. 

To  start  TP  the  following  JCL  statements  are  reguired: 

//TP  JOB  (Optional  Data) 

//GO  EXEC  XTP 


The  single  region  control  program,  UTTPDRVR,  is  executed 
to  attach  the  TP  Monitor  and  TP  Supervisor.  UTTPDRVR 
obtains  the  PAPM  parameter  information  from  the  EXEC 
statement  to  attach  the  appropriate  TPMON  and  TPSUP  load 
modules.  In  a S/370  MVS  environment,  the  unit  type  to  be 
used  for  dynamic  allocation  of  temporary  data  sets  by 
application  programs  may  be  specified  here. 


The  format  of  the  PAPM  parameter  is: 

iTPSUP 
TPSUP  XXX 


PAR  H = 


•TPMON 

TPHONXXX 


‘J 


. WORKUNIT  = S YSALLDA 


xxxxxxx 


where: 


,TP= REFORM AX 50  ' 

REFORM ATnnn 


tEfiO]! 

TPMONXXX  The  name  of  the  TP  Monitor  load 

module.  The  default  is  TPMON.  The 
user  may  specify  an  alternate  load 
module  name.  The  first  five 
characters  of  the  alternate  name 
must  be  TPMON,  and  the  monitor  must 
be  linkedited  on  the  NIPS  system 
library  referenced  in  the  STEPLIB  DD 
statement  in  the  XTP  procedure. 


X£SU£ 

TPSUPXXX  ’’’he  name  of  the  TP  Supervisor  load 

module.  The  default  is  TPSUP.  The 
user  may  specify  an  alternate  load 
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module  name.  The  first  five 
characters  of  the  alternate  name 
must  be  TPSUP,  and  the  Supervisor 
must  be  linkedited  or  the  NIPS 
system  library  referenced  on  the 
STEPLIB  DD  statement  in  the  XTP 
procedure . 

HOP.  K UNITES  YSALLD  A 

XXXXXXX  The  generic  name  or  device  type 
to  be  used  for  dynamic 
allocation  of  temporary  data 
sets  by  application  programs  in 
a S/370  MVS  environment.  The 
default  is  SYSALLDA. 

TP=RgPOBMAT50 

REFORMATnnn  The  number  of  lines  that  are 
assigned  per  terminal  on  the  DASD 
Input  Message  Queue.  The  default  is 
REFORMAT50  which  causes  50  lines  per 
terminal  to  he  formatted  on  the  IMQ. 
The  DASD  IMQ  is  reformatted  when  the 
monitor  is  restarted.  The  user  may 
assign  a different  number  of  lines 
per  terminal  by  specifying 
REFORM ATnnn , where  nnn  is  1-999,  as 
long  as  the  total  SPACE  assigned  to 
the  IMQ  data  set  will  accommodate 
all  the  terminals.  This  parameter 
has  no  meaning  if  an  incore  IRQ  is 
used. 

The  UTTPDRVR  program  loads  and  attaches  the  monitor  and 
supervisor  load  modules.  The  monitor  is  attached  with  the 
same  priority  as  the  control  program  and  the  supervisor  is 
attached  with  a priority  of  one  less  than  the  monitor.  A 
HAIT  is  issued  for  the  completion  of  either  task.  If  either 
task  terminates  abnormally  both  tasks  are  detached  and 
deleted.  Both  tasks  are  then  restarted. 

Uhen  the  monitor  completes  its  initialization,  TP 
TERMINALS  OPEN  is  displayed  on  the  operator's  console.  When 
the  supervisor  completes  initialization,  TP  SUPERVISOR  READY 
is  displayed  on  the  console.  Both  are  nonending  tasks  and 
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require  manual  cancellation.  To  assist  in  this,  the  monitor 
also  types  the  following  request  to  the  operator: 

TP  STANDING  REQUEST.  REPLIES  ARE  'ENA',  'DISA', 

•MSG',  1 PRTY ' , 'TPS',  OP  • TPM • . 

This  remains  as  an  outstanding  request  for  the  duration 
of  the  TP  job.  The  reply  of  'ENA'  is  used  bv  the  operator 
to  activate  a terminal  allocated  to  the  TP  job  (see  section 
7 . 14 .8  of  this  document  for  a description  of  this  option). 
The  reply  of  'DISA'  is  used  by  the  operator  to  place  a 
terminal  allocated  to  the  TP  job  in  an  inactive  status  (see 
section  7.14.8  of  this  document  for  a description  of  this 
option).  The  reply  of  'MSG  * is  used  by  the  operator  to  send 
messages  to  terminals  (see  section  2. 5. 2.2  of  the  Terminal 
Processing  Manual  for  a description  of  this  option).  The 
reply  of  ' PRTY ' is  used  to  alter  the  priority  of  a terminal 
(see  section  7.12.1  of  this  document  for  a description  of 
this  option).  If  the  operator  replies  'TPS',  the  TP 
Supervisor  task  will  come  to  a normal  end.  If  the  operator 
replies  'TPM'  both  the  T*>  Monitor  and  TP  Supervisor  tasks 
will  end.  If  terminal  users  are  still  active  when  a request 
has  been  made  to  cancel  the  TP  Sueprvisor  task,  the  operator 
is  given  the  option  of  restarting  the  TP  Supervisor. 
Otherwise  the  TP  job  will  end.  The  operator  may  also  use 
the  standard  OS  job  cancellation  command  to  terminate  the  TP 
job. 


7.3  TP  Procedure 

The  XTP  cataloged  procedure  is  used  to  execute  the 
UTTPDRVR  routine.  ’’’he  function  of  this  routine  is  to 
provide  a means  to  initiate  the  NIPS  ’’’P  Monitor  and  TP 
Supervisor  and  have  them  execute  within  a single  region  or 
partition.  The  monitor  is  attached  with  the  same  priority 
as  the  UTTPDRVR  program,  and  the  supervisor  is  attached  with 
a priority  of  one  less  than  TPHON . 

# To  provide  a better  understanding  of  the  procedure  and 
to  assist  in  tailoring  the  procedure  to  an  installation, 
each  DD  statement  of  a typical  single  region  XTP  procedure 
will  be  discussed. 
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Execution  of  UTTPDRVR  requires  DD  cards  to  support  both 
tae  TP  Monitor  and  TP  Supervisor.  To  support  the  TP 
Monitor,  the  XTP  procedure  requires  DD  cards  to  identify 
the  NIPS  program  libraries,  two  or  three  DD  cards  for  disk 
data  sets,  one  or  more  DD  cards  for  2260,  2250,  1050,  3270, 
and/or  2741  terminals,  and  other  optional  DD  cards.  The 
information  required  in  each  DD  card  is  as  follows: 

//STEPLIB  DD  DSN=PT?.JOBLIB,DISP=SHR 
//  DD  DSN=FFS.JOBLIB,DISP=SHR 

These  DD  statements  identify  the  NIPS  program  libraries. 

//INNSGQ  DD  DISP=SHP,DSNAME=TPIMQ 

This  data  set  was  created  and  cataloged  when  the  TPQ  job 
in  appendix  A was  executed  if  an  incore  IMQ  was  not 
specified  (see  section  7.4  TP  Monitor  Generation  paragraph 
a.  Selecting  TP  Monitor  Options).  If  an  incore  IMQ  is  being 
used,  the  DD  statement  is  not  used. 

//OUTMSGQ  DD  DISP=S HR , VOL UME=P EF=* . INMSGQ 
//OMSGQ  DD  DISP=S  HR , VOL UME=  REF "INMSGQ 

These  DD  statements  is  used  to  reference  all  Output 
Message  Queues  when  the  Input  Message  Queue  is  allocated  on 
disx. 


//OUTMSGQ  DD  DISP= SHR , VO L=SER=vo lid , U N IT=un it name 
//OMSGQ  DD  DIS  P=  SH  R, VOL -SER=  vo  lid, UNIT*:  unit  name 

These  DD  statements  are  used  to  reference  all  Output 
Message  Queues  when  the  Input  Message  Queue  is  maintained  in 
core.  The  volid  and  unitname  must  be  supplied  to  identify 
the  volume  on  which  all  Output  Message  Queues  are  allocated. 


//STATRECS  DD  SYSOUT  = A 

This  DD  statement  defines  the  data  set  used  by  the 
monitor  to  record  all  TP  accounting  records.  It  is  required 
if  the  QTPMOPT  macro  specified  ACCTNG=YES  at  Monitor 
generation  tine.  The  distributed  Monitor  requires  this  DD 
statement. 
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//ACCTSAVE  DC  TAPE-OP-DISK 

This  DD  statement  defines  the  same  information  as  the 
STATRECS  DD  statement.  Its  purpose  is  to  save  the 
accounting  information  either  on  tape  or  disk  for  further 
processing.  Absence  of  this  card  will  result  in  no  action 
being  taken  to  produce  the  accounting  records  on  some  media 


other  than  printed 

output 

• 

//DD5 

DD 

UN IT=  XXX 

//D51 

DD 

TJ  N I T=  X X X 

//DD6 

DD 

UNI T= (2260-1,8) 

The  above  DD  statements  define  the  2250  and  local  2260 
terminals.  In  the  case  of  the  distributed  Monitor,  these 
are  the  only  terminal  definition  cards  necessary. 
Additional  terminal  DD  cards  are  added  as  described  in  TPMON 
Generation. 

Only  the  UNIT=operand  is  required,  using  any  valid  name 
acceptable  at  the  installation.  UNIT=hexaddr  is  always 
valid  for  the  2250  and  UNIT= (2260-1 ,n)  for  the  2260 
terminals  where  n is  the  number  of  2260’s  desired. 

Provide  the  UNIT  hex  addresses  for  the  2250s  at  your 
installation  for  XXX  in  the  DD5  and  D51  DD  statements.  If 
no  2250  support  is  required,  remove  the  DD5  and  D51 
statements  from  the  procedure. 

The  distributed  TPMON  is  generated  to  support  zero,  one, 
or  two  2250  and  zero  to  eight  local  2260  terminals.  The 
distributed  procedure  for  executing  the  TPMON  is  designed 
for  cunning  with  one  2250  and  one  to  eight  local  2260s. 
Consequently,  modifications  will  have  to  be  made  to  the 
procedure  for  the  unique  terminal  configuration  of  any 
particular  installation. 

The  difficulty  involved  in  removing  from  t he  procedure 
DD  cards  defining  serviceable  units  suggests  that  the 
easiest  method  for  executing  the  TP  job,  at  installations 
with  several  terminal  configurations,  would  be  to  add  the 
necessary  DD  cards  as  overrides  at  run  time. 

If  a user  wishes,  he  may  create  a procedure  to  be  run 
with  any  combination  of  a particular  configuration  of  2250s, 
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and  local  and  remote  2260  and  3270  terminals.  To  do  so,  in 
addition  to  the  above,  the  user  should  include: 

a.  One  DD  card  for  each  2250  generated  into  TPMON. 
The  names  of  these  DD  cards  must  correspond  to  the 
label  appearing  in  the  name  field  of  the  ^TPDD 
macro  statements  for  the  2250s  (see  TP  Monitor 
Generation)  . These  PD  statements  should  take  th^> 
for  m : 


//DD5  DD  U NI T=  XX  X 

where  XXX  is  the  hex  address  of  the  2250  being 
allocated . 


b. 


One  DD  card  for  each  group  of  one  to  eight  2260s. 
As  was  the  case  with  2250s,  there  should  be  one  DD 
card  in  the  procedure  for  each  QTPDD  card  on  the 
TPMON  generation  deck  defining  2260s.  These  DD 
statements  should  take  one  of  two  forms  for  2260 
groups  [i.e.,  those  defined  with  UNITS=  two  or  more 
on  the  QTPDD  card] 

//DD6  DD  UNIT=  (2260-1  ,N) 


where  N = the  number  of  2260s  to  be  allocated  (may 
be  any  nonzero  number  equal  to  or  less  than  the 
number  in  the  operation  field  of  the  ‘UNITS' 
operand  on  the  corresponding  QTPDD  card) . 

For  individually  defined  2260s 

//D61  DD  UN IT=  XXX 


where  XXX  is  the  hex  address  of  any  particular 
2260. 


c.  One  DD  card  or  concatenated  string  of  DD  cards  for 
each  1050,  2741,  3270  or  remote  line.  If  these 

terminals  have  system-generated  group  names,  then 
only  one  DD  card  for  each  terminal  type  need  be 
present.  If  no  system-generated  group  names  exist, 
or  if  specific  telephone  lines  are  desired,  then 
each  line  should  be  allocated  by  hex  address.  A 
concatenated  string  of  DDs  for  each  terminal  type 
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is  then  required  with  the  label  in  the  nane  field 
on  the  UTPDD  and  QTPLINE  macro  statements  for  that 
terminal  type. 

These  DD  statements  should  take  one  of  the 
following  forms: 


//SEl 

DD 

UN IT= (qroupname. 

n) 

qroupname 

= the  SYSGEN'ed 

groupname 

n 

= the  number  of 

lines. 

//RE1 

DD 

UN  TT=  XXX 

// 

DD 

UNTT=XXX 

// 

DD 

UNI'T’=XXX 

where  XXX  = the  hex  address  of  each  line. 

d.  The  desired  number  of  NOUNITn  DD  cards,  the  purpose 
of  which  is  to  allow  the  user  to  allocate  only 
those  units  which  he  specifically  wishes  to  use. 

The  format  of  these  DD  cards  should  be: 

//NOUNITn  DD  DDNAME  = DUMMY  or  for  symbolic 

(or  any  unique  name)  procs  default  to  any 

name  not  in  the  Monitor 
JCL. 

There  should  be  n- 1 NOUNITn  DD  cards,  where  n = the 
number  of  DD  cards  in  the  procedure  defining  units 
or  groups  of  units  for  the  TPMOV  to  service. 

These  DD  cards  must  appear  in  the  procedure  before 
any  of  the  DD  cards  defining  serviceable  units. 

To  prevent  any  unit  or  groups  from  being  allocated,  a 
user  must: 

a.  Override  the  DUMMY  with  the  DD  card  (s)  defining 
device  (s)  which  are  not  required. 
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b.  Override  the  NOUNTTn  DP  card  (s)  so  that  the  DDNAMF 
parameter  specifies  the  DD  nam°(s)  of  the 
unnecessary  DD  cards. 

Note:'  Simply  overriding  with  DD  DUMMY  for  the  unwanted  DD 
cards  is  not  sufficient. 


For  example,  a user  whose  procedure  contains  two  DD 
cards  for  2250s  and  one  DD  card  for  2260s  may  run  without 
allocating  any  2250s  by  coding: 


//  EXEC 

X^P 

//NOUNIT1 

DD 

EDNA  MF=DD5 

//NOUNT'r2 

DD 

DBNA  ME=D  51 

//DD5 

DD 

DUMMY 

//D51 

DD 

DUMMY 

A procdure  for 

TP 

may  fce  created  which  contains  all  the 

st  atements 

necessary 

to 

allocate  all  of  the  defined  terminal 

devices. 

The  following 

TP  procedure  illustrates  all  the 

statements 

needed 

for 

the  TPMON.  Other  DD  statements  are 

required 

to  support 

TP  application  programs  and  are 

described 

in  subsequent 

paragraphs. 

//XTP 

PROC  T 

PIMQ=T?IMQ, 

// 

VOMQ  = 'PEF=*.INMSG(J,,UOMQ  = , 

// 

UDD5=2E0,  UD51=2p1 ,UDP6=' 2260-1  • 

// 

UD6  1=*  2260-t' ,NDD6=8,ND61  = 5, 

// 

HBE1=021,URE6=02F,OMIT1=NULL1, 

// 

0MIT2=NULL2,0HIT3=NULL3,0MI?4=NT:LL4  , 

// 

OMI T5=NMLL5 

//TPMON5UP 

LXEC  PGM= 

UTT 

PDRV  R ,TT K F = i 43 ° 

//INhSUQ 

nn 

DI5t=SHF,  DSN  AM  P=R?PT  MO 

//OUTdSO 

DD 

F PACP= (”?  K, 0)  , VOLUME  = 6 VOMO , U NIT=0UOMQ 

//ST ATRECS 

DD 

F YSOU"=A 

//S  YSUD'JM? 

DD 

q YFPUT=  A,  SP  AC T=  (,r  PK,  (10,50)  ) 

//NO-JNIT1 

DD 

DPU  A m p = p- 0 M IT  1 

//t.  JJNIT2 

DD 

PPV  AME-f>OMT"2 

//NOUN  17  3 

DD 

DDKAMT=KOMIT 3 

//NOUN  IT 4 

DD 

nPN  A M ~=(>OM  rr'  4 

//N  J:J'JIT5 

DD 

DD  U A M T=f'  OM.  I"’  5 

//DD5 

DD 

UNI'T!=i>UDr5 

//D51 

DD 

UUTT=6UD5  1 

//uDo 

DD 

nyys  (5UDD6  ,6NPD6) 

//D6  1 

rr 

"NiT=(6nnr>i,tvD(si) 
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//R^l 

//hE6 


DD 

DD 


U NT  T=ftUP  r 1 

unit=su?e6 


To  r-x-jcute  TP  and  allocate  Two  225Cs,  11  local  226ns,  three 
remote  1050?  and  Two  remote  22f>0s,  ore  need  only  code 


// 


' X EC 


X TP 


To  execute  TP  without  allocating  any  remote  devices,  on<= 
woulu  code 

//  EXEC  XTP, OMITIr^i  ,OMI?2=?E6 
//PEI  DO  PTjm  m y 

//tvEfe  DD  DUMMY 

TO 

code 


execute  TP 

and 

allocate  only  one  local  22*0,  one 

would 

//  EX* 

XTp  ,n 

T1=DD5,0KIT2=D51,0MTT3=DD6, 

X 

// 

//DD5 

DD  ' 

dummy 

OMT?4=RE1 ,0MT75=PE6,ND61 =1 

//D51 

DD 

DUMMY 

//LU6 

DD 

DUMMY 

//F  FI 

DD 

DUMMY 

//!•  E6 

DD 

DUMM  Y 

To  s up  port. 

the 

TP  r> 

upervisor  task  the  following 

statements  should  be  added  To  the  TP  procedure,  depending  or. 
tne  TP  application  program  (s)  being  run  and  the  OS/VS 
enviroum ont . 


//£.  YSUT1 

DD 

//SY  5UT2 

DD 

//SYSUT3 

DP 

//S YSUT4 

DD 

SP  AC  E=  (TP  K , 0 ) , Ilf:  TT  = 23  14 
3PACE=('r?K,0)  , UN  IT  = 2314 
Sn  AC  E=  (T^  K , D ) , UNI"=  (?314,SEP=SYSUT1) 


Tne  above  DD  stat aments  define  work  data  sets  for  QUIP  and 
SJDA.  They  are  not  required  ir,  an  MVS  environment. 


//DAT A FIL  £ DD  DISP*SHP , DSNAME=DUMMY. PILE, 
//  UNTT=  (2’‘I4,P,DSM:,EP) 
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Inns  DD  stiuenpn*  is  uspfl  to  allocate  the  ISAM  data  file  if 
it  co&sists  cf  on?  volume.  Tt  is  not  required  ir.  an  MV? 
environment. 

//S AMFILF  DD  DISP=SHF,  DS  N=  Off  KM  Y . FILES,  X 
//  TJNIT=  (21 14  ^DF'EF) 

This  DD  statement  is  used  * o a]loca*f  the  SAM  data  file, 
whicn  must  na  direct  access  resident.  Tt  is  not  required  in 
an  MVS  environment. 


f 

//TFT  Dti  DTSP^SHF,  r'SNAME=DdMMY.:7ILF, 

//  U V T T = (2  314,F,DFFF3) 

This  DD  statement,  is  used  * o allocate  the  ISAM  F’7'”  used  with 
a non-NlPS  data  file  allocated  by  the  PATAF1LD  or  SAM7ILD  DD 


t 

statement.  This 

en  vironm  ant . 

state 

inent  is  not  required  in 

1 

( 

//DATAFIL1 

DD 

F>  ISP®  SHI'  ,DSN'AMF=DUMMY.T'ILT 

J 

// 

TJNTT®  ( 2 31  4, 11,  D^FFF) 

//DAT AFIL2 

DD 

DI"r>=S:i?  , DSN  AM  5=  DUMMY  . FTLr 

// 

(J  NTm=  (2  *1  4,  P.  DEFEP) 

Thes-.i  DD  statements  are  used  *0  allocate  the  ISAM  secondar  • 
data  riles  when  Interfile  Output  is  used.  If  more  than  tm 
secondary  files  are  required,  additional  DD  statements  wit  . 
the  names  DATA7IL3  through  DATAFTL0  are  required,  one  for 
each  additional  secondary  file.  a maximum  of  nine  secondary 
files  is  allowed.  The  parameters  required  on  each  of  the 
additional  DD  statements  are  the  same  as  those  above.  "’hese 
statements  are  nor.  required  in  an  MVS  environment. 

//FFT 1 DD  PTSP  = ?n'>,  DSNAMF  = D1JWVY.,7ILF, 

//  t]NIT=(2314,P,P”?FS) 

//rFT 2 DD  DISP=SHF,  DS  »IA  MF=PU  MM  Y . FIL17, 

//  HNI  T=  (2  3 1 4 , P.  Di’^F  F ) 

These  DD  statements  are  used  to  allocate  rhe  ISAM  FFTs  used 
with  non-NIPS  data  files  allocated  to  the  OATAFILI  and 
DATAFIL2  DD  statements.  If  more  than  two  secondary  files 
are  required,  additional  DD  statements  (named  3 through 

FFT9)  are  required,  one  for  aach  aadi*ional  secondary  file. 
A maximum  of  9 secondary  fil°  F17?  references  is  allowed  and 
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the  parameters  for  each  additional  DD  statement  are  the  same 
as  aoove. 

If  System  Management  Facilities  (SMF)  information  is 
required  for  secondary  files,  DUMMY .FILS  should  be  replaced 
by  tne  secondary  file  name.  There  should  then  be  a unique 
DATAFILn  DD  statement  for  each  secondary  file  that  is  to  be 
referenced  by  QUIP. 

In  an  non-MVS  environment,  QUIP  and  SODA  are  able  to 
dynamically  allocate  fil«s  only  so  long  as  the  DSNAME  fields 
on  the  DATAFILE  and  DATAFILn  PD  statements  reference  the 
name  of  a dummy  file  (i.e.,  a DSN  beginning  with  "DUMMY."). 
If  DATAFILE  points  to  any  other  data  file,  then  only  files 
on  the  same  pack  may  be  queried  as  the  primary  file. 
Similarly,  if  any  DATAFILn  points  to  a specific  file,  then 
only  files  on  that  same  pack  may  be  queried  as  secondary 
files  associated  with  that  DD  statement.  Attempts  to  query 
files  on  other  packs  will  result  in  an  S413  ABEND.  In  an 
MVS  environment  dynamic  allocation  of  the  requested  file  is 
performed  without  the  requirement  for  a DD  statement. 

//DATAPILA  DD  UNIT=  (23 14 , 2)  , DS  N=DUMNY.  FILA, 

//  SPACE=  (TFK,0) 

This  DD  statement  is  used  to  allocate  the  data  file  if 
it  requires  two  volumes.  It  is  not  required  in  an  MVS 

environment. 

//DATASMFx  DD  DS N= f ilena me , DISP= SHR 

This  DD  statement  defines  a data  file  for  which  System 
Management  Facilities  (SMF)  information  is  required.  The 
suffix  on  the  ddname  may  be  any  unique  numeric/alpha 

character.  The  'filename9  is  the  data  set  name  for  a file 

to  be  queried.  One  DD  statement  is  required  for  each  file 
that  is  to  be  queried  by  QUIP.  It  is  not  required  in  an  MVS 
environment. 

//SLIB  DD  DISP=SHR,DSN=DUHHY.PILEL 

//  DD  DISP=SHF,DSN=FFS.JOBLIB 

These  DD  statements  are  used  to  allocate  and  define  the 
user  and  system  libraries  required  for  the  various 
applications  in  a non-MVS  environment.  The  user  library  may 
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contain  (a)  tables  and  subroutines  associated  with  field 
conversion;  (b)  QUIP  queries  and  structured  RITs  to  be 
referenced  with  the  QUIP  LOAD  operator;  (c)  formats  utilized 
by  Pjpr.ATTER;  and  (“)  various  EDIT  applications.  The  system 
library  (FFS.J03LIB)  contains  standard  data  conversion 
subroutines  and  standard  formats  for  EOPflATTER.  In  an  non- 
BVS  environment,  a user  library  may  be  dynamically  allocated 
only  so  lonq  as  the  BSNAMF  cn  the  first  SLIB  DD  statement 
references  the  name  of  a dummy  library  ( a data  set  name 
beginning  with  "DUBBY. ") . When  this  is  the  case,  FORBATTER 
and  EDIT  attempt  to  allocate  the  specified  user  library  and 
teplce  the  uumay  library  with  the  user  library.  QUIP  does 
the  same  for  any  library  specified  on  a LOAD  operator.  QUIP 
and  SODA  always  attempt  to  allocate  a file  library.  The 
name  ot  the  file  library  is  obtained  by  adding  the  suffix 
"L"  to  the  data  set  name  of  the  file.  (For  QUIP,  the  data 
set  name  of  the  primary  file  is  used  if  Interfile  Output  is 
requested;  and  if  the  file,  is  a SAB  file,  the  ending  "S"  is 
replaced  by  "L"  to  obtain  the  library  data  set  name.)  If  a 
file  library  with  this  data  set  name  cannot  be  located  and 
the  name  is  a qualified  da*a  set  name,  one  final  attempt  is 
made  to  allocate  a library  using  the  NIPS  file  name  rather 
than  the  full  qualified  data  set  name.  If  the  file  library 
can  be  located  and  allocated,  it  internally  replaces  the 
dummy  library  in  the  concatenation  of  data  sots  associated 
with  the  SLIB  DD  statements  so  that  searches  for  tables  and 
subroutines  start  with  the  file  library.  If  the  file 
library  cannot  be  allocated  and  if  a file  library  is 
required  for  successful  execution  of  the  application,  an 
appropriate  error  condition  will  be  displayed. 

In  an  BVS  environment  these  DD  statements  define  the 
\* braries  required  for  any  application  which  does  not 
i-.  juire  the  dynamic  concatenation  of  a file  library  with 
,stem  libraries  (defined  on  BVSLIBnn  DD  statements 
(.“scribed  below)  . if  a file  library  cannot  be  located  or 
allocated  the  libraries  defined  or.  the  SLIB  DD  statements 
will  be  used. 


//TPDUBP  DD  SYSOUT^A 

This  DD  statement  is  used  for  the  output  from  a snapshot  of  core 
taken  during  any  abnormal  termination  of  a QUIP  query. 

//EDITDUBP  DD  SYSOUT=A 
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This  DD  statement  is  used  for  the  output  from  a snapshot 
of  core  taken  during  any  abnormal  termination  of  an  EDIT 
function . 

//SYSUDUMP  DD  SYSOHT=A 

This  DD  statement  is  used  to  obtain  a core  dump  during 
abnormal  termination  of  a run. 

//SNAPSHOT  DD  SYSOOT=A 

This  DD  statement  is  used  for  the  output  from  a SNAP 
dump  of  core  taken  during  program  error  recovery  for  QUIP 
and  FORMATTER. 

//PL1D0MP  DD  SYSOOT=A 

This  DD  statement  is  used  to  obtain  a core  dump  during 
abnormal  termination  of  SODA. 

//SDCONSOL  DD  UNIT=SYS DA,SPACE= (2300 , (5, , 1)  ) 

This  DD  statement  is  used  to  store  the  status  of  each 
console  or  terminal  for  a SODA  run. 

//SDKNSET  DD  S PA C5= (CY L, (1 , 1 )), UNITES YSOUT,  X 

//  DCB  = (PECFN=F,  BLKS  IZE  = 1 004) 

This  DD  statement  is  used  to  record  all  key  changes  made 
to  the  file. 

//SYSLMOD  DD  SPACE= (TRK,  (10, ,4) ) , UNIT=S YSDA,  X 

//  DCB=F?S. JOBLIB 

• 

This  DD  statement  is  used  to  store  copies  of  all  logic 
statements  used  in  a SODA  update. 

//SYSPRINT  DD  SYS0UT=A 

This  DD  statement  is  used  to  print  PL1  error  messages 
from  SODA  and  to  print  the  output  from  the  TPDUMP  program. 

//SYSONLIN  DD  SYSO0T*A 
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This  DD  statement  defines  the  output  device  that  will 
receive  the  Output  Message  Queue  when  the  dump  program 
(TPDUMP)  is  called. 

//AMSGQ  DD  UNIT=SYSDA,SPACE=(TFK,  (0,5)  ) 

This  DD  statement  defines  a message  volume  for 

Teriainal/Terminal  communication.  If  the  IMQ  or  OMQ  is  sent 
to  another  terminal,  it  is  first  copied  to  a temporary  data 
set  on  this  volume  by  BLAST.  It  is  not  required  in  an  MVS 
environment. 

//SYSIN  DD  DUMMY 

This  DD  statement  defines  the  input  data  set  for  the 
Supervisor.  If  there  is  no  input,  the  statement  may  remain 
as  above  with  DUMMY  indicating  no  data  is  to  follow.  ”or 

the  distributed  Monitor  no  input  data  is  required.  To 
expand  the  Supervisor  capabilities  to  support  other 
applications  see  the  discussion  under  TPSUP  Variations. 

//EDITLIB  DD  DSN  = D HMM Y.  F ILEL, DIS P=SH R 

or  for  a MVS  system: 

//EDITLIB  DD  DUMMY 

This  DD  statement  is  used  to  allocate  the  user  specified 
library  in  EDIT;  in  FORMATTER  it  is  used  to  allocate  the 
library  which  contains  new  formats.  It  is  not  required  in 
an  MVS  environment.  In  a MVS  environment  the  EDITLIB  DD 

statement  may  be  coded  with  DUMMY  to  indicate  that  no  data 

is  to  follow. 

//E DCONSOL  DD  SP ACE= (TP K , ( 5, , 4 ) ) , UNIT  = S YSD A 

This  DD  statement  defines  a partitioned  data  set 
containing  communications  records  used  for  various  sections 
of  EDIT  and  COEDIT. 

//XINDEX  DD  DSN  = DUMMY. F ILEX , DIS P=S HR 

This  DD  statement  is  used  to  allocate  the  index  data  set 
for  the  data  file  if  Secondary  Indexing  is  used.  It  is  not 
required  in  an  MVS  environment. 
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//SUBFILE  DD  UNIT* S YSD A,  SP ACE=  (C Y L,  (0 , 2,  1 0)  ) 

This  DD  statement  assigns  a system  work  volume  on  which 
a QUIP  subfile  partitioned  data  set  is  allocated  when 
requested  by  the  user.  In  FORMATTER  it  is  used  to  allocate 
the  library  used  for  new  formats.  The  secondary  quantity, 
which  specifies  the  amount  of  additional  space  to  be 
allocated  if  required,  may  be  increased  according  to 
installation  requirements.  Similarly,  the  number  of 
directory  records  may  also  be  increased  as  required.  This 
statement  is  not  required  in  an  MVS  environment. 

//MENUS ET  DD  DSN =DUNHY . F ILEL , DISP=SHF 

This  DD  statement  is  used  to  define  the  distribution 
data  set  for  view.  The  distribution  data  set  is  a 
partitioned  data  set;  its  logical  record  length  must  be  80, 
and  its  blocksize  may  be  any  multiple  thereof.  The 
distribution  data  set  contains  the  previously  stored  output 
reports,  which  can  be  selected  by  VIEW.  It  must  contain  a 
member  named  MENULIST  which  is  made  up  of  titles  and 
descriptions  of  the  stored  reports. 

Note:  VIEW  is  able  to  dynamically  mount  distribution  data 
sets  as  long  as  the  DSNAME  field  on  the  HENUSET  DD  statement 
contains  a data  set  name  that  begins  with  "DUMMY." 

//MVSLIB01  DD  DSN=FFS.JOBLIB,DISP=SHR 

This  DD  statement  identifies  the  first  library  that  is 
to  be  concatenated  with  the  file  library  for  field 
conversion  with  QUIP  and  SODA  applications  in  an  MVS 
environment.  It  is  not  required  in  any  other  environment. 
Additional  libraries  that  are  to  be  included  in  the 
concatenation  with  the  file  library  can  be  specified  on 
additional  DD  statements,  each  with  a unique  ddname 
N VSLIBnn , where  nn  is  a 2-digit  sequence  number  starting 
with  02  and  incremented  by  one  for  each  data  set  (up  to  15)  . 
The  order  of  concatenation  is  in  the  NVSLIRnn  ascending 
sequence  (e.q.,  HVSLIBO 1, MV SLIB02 , HVSLIBO 3, etc. ) . Por  those 
applications  which  do  not  employ  a file  library,  this 
concatenation  technique  is  not  applicable.  Field 
conversion,  if  required,  is  performed  using  the  libraries 
identified  with  the  SLIB  DD  statement. 
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7.3.1  JCL  Considerations  for  EDIT  Generated  Batch  Jobs 

When  a SUBNIT  command  is  issued  to  enter  a job  stream 
generated  at  a terminal  for  batch  processing,  EDIT  copies 
the  job  stream  from  the  terminal's  wort  area  to  one  of  three 
data  sets  or  devices.  The  selection  of  a data  set  and  the 
subsequent  method  of  handling  the  job  stream  is  dependent  on 
the  presence  of  either  a HASPRDP  or  SHAFDASD  DD  card  or  the 
absence  of  both.  EDIT  scans  the  DD  names  and  uses  the  first 
applicable  DD  name  found. 

If  neither  DD  name  is  found,  EDIT  dynamically  names, 
allocates  and  catalogs  a data  set  for  the  job  stream  and 
activates  an  internal  reader  to  read  it  into  the  system  job 
queue.  The  name  of  this  reader  is  TPPDR  080 . It  is 
distributed  with  the  other  NIPS  procedures  on  FES.PROCLIB 
and  must  be  copied  to  SYS1. PROCLIB. 

The  HASPRDR  DD  card  is  included  in  the  job  stream  to 
indicate  that  an  internal  reader  is  to  be  used  for  job 
entry.  A HASP  pseudodevice  or  a NVS  internal  reader  may  be 
specified  depending  on  the  operating  system  in  use. 

In  a HASP  environment  the  job  is  submitted  to  the  HASP 
internal  reader.  The  DD  statement  must  contain  UNIT=2520 
and  DISP=OLD.  The  2520  unit  is  a pseudodevice  and  must  be 
defined  at  S/360  OS  System  generation  time.  On  some  HASP 
systems  UNIT=INTRDR  should  be  coded  to  invoice  the  HASP 
internal  reader. 

In  the  NVS  environment  the  DD  statement  must  contain 
SYSOUT=(A,INTPDR) . INTRDR  is  t he  name  of  the  NVS  internal 
reader.  This  DD  statement  is  required  for  the  EDIT  SUBMIT 
command  to  function  in  a MVS  environment. 

If  the  SHARD AS D DD  card  is  used,  it  must  contain  a 
DSNAME  of  user  choice,  VOL=SER=  (serial  number)  if  not 
cataloged,  and  DISP- (MOD, KEEP) . EDIT  assumes  the  device  is 
a shared  DAS D and  issues  the  RESERVE  macro  to  loclc  out  other 
users  or  computer  systems  until  the  job  stream  is  completely 
written,  at  which  time  a DEQ  macro  is  issued  to  free  the 
device.  The  job  stream  is  written  sequentially  in  800- 
character  blocks  of  80-character  records.  The  mention  of 
the  SHARDASD  DD  card  is  not  to  point  out  any  available 
option  or  alternate  method  of  processing  these  batch  jobs. 
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This  DD  card  merely  provides  the  means  for  devising  other 
methods  and  establishing  procedures  tailored  to  an 
installation's  requirements.  Jobs  submitted  to  this  data 
set  can  be  processed  at  a later  time  or  concurrently  on 
another  computer  system  if  the  device  is  a Shared  DASD.  In 
either  case,  the  batch  jobs  will  not  compete  with  online 
operations  for  computer  resources. 


7.3.2  JCL  Considerations  for  ALC  Source  Code  Verification 

When  an  installation  will  be  using  the  ALC  source  code 
verification  feature  of  EDIT,  the  following  DD  statements 
must  be  included  in  the  TP  JCL  deck. 

//ASMIN  DD  UN IT=  6S  TG, SPACE  = (CYL,  (0,1)) 

//ASMOUT  DD  UNIT=&STG,SPACE=  (CYL,  (0, 1)  ) 

//ASMWK1  DD  UNIT=&STG,  SPACE=  (CYL,  (3, 1)  ) 

//ASMWK2  DD  UNIT=fiSTG, SPACE= (CYL,  (3, 1) ) 

//ASMWK3  DD  UN  IT  = RSTG,  SPACE=(CYL,  (3,1)) 

The  above  data  sets  are  used  to  invoke  the  assembler. 

//ASMPRT  DD  SYSOUT=A 

This  DD  statement  is  used  when  the  user  invokes  the 
assembler  LIST  option. 

//ASMDUM  DD  DUMMY 

This  DD  statement  is  used  to  supress  undesired  assembler 
output  functions. 

//SYSLIB  DD  DS  N=& JCBM ACRO, DISP=S HP 
//  DD  DSN=SYSl.MACLIB,DISP-SHR 

The  above  DD  statements  provide  the  assembler  with  needed 
macro  libraries. 

khen  these  DD  statements  are  not  included  in  the  JCL 
deck,  EDIT  will  suppress  all  attempts  to  verify  ALC  source 
code. 
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7.4  TP  Monitor  Generation 

Regenerating  TPMON  involves  changing  macro  stateness  in 
the  TPMONGEN  job  and  executing  it.  The  macros  QTPHOPT, 
QTPDP,  QTPPFQG1,  OTPPROU2,  QTPPPOG3,  QTPGEND,  and  QTPLINE 
may  be  used  to  create  tables  and  control  blocks  used  by  the 
monitor.  All  TP  modules,  except  for  the  optional 
installation  written  validation  subroutine,  necessary  for 
generating  any  TPMON  are  contained  in  FFS.JOBLIB.  (For 
additional  information  on  the  optional  installation 
validation  subroutine,  see  section  7.14  of  this  manual.) 
Error  conditions  produced  during  TP  Monitor  generation  are 
described  in  section  7.10  of  this  document. 

a.  Specifying  TP  Monitor  Options  - Specify  the  TP 
Monitor  options  using  the  QTPHOPT  macro  in  the 
following  format: 


QTPHOPT 


ACCTNG= 


YES 


NO 


, FtJLLP  AOE= 


YES 


NO 


The  options  are  keywords  as  follows: 


, VALID=XXXXXXXX 


— 

- 

— 

J 

f>!5) 

fnn  1 

[H2 

,DVfl=  , 

ss } 

,IHQ=  ( 

1 

DASD_ 

, ODEW  K=  , 

YES 

_ 

_ 



YES 

ACC  T NG  

NO 


PULP AGE= 


NO 

YES 


The  ACCTNG  option  defaults  to  YES 
which  indicates  that  accounting  data 
should  be  supplied  by  the  TP 
Monitor. 


The  FULPAGE  option  defaults  to  NO 
which  indicates  single  line  writes 
are  made  from  the  OMQ  to  the 
terminal  display  screen.  If 
’ULPAGE* YES  is  specified,  a buffer 
large  enough  for  a full  page  write 
is  created,  and  writing  a full 
screen  to  local  CTP  terminals  is 
accomplished  by  a single  write 


H 


■A 
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instruction.  If  FULPAGE  option  is 
specified  as  YES  at  aonitor 
generation  tiae  and  the  type  of  CPT 
is  a 3277/3275,  TPPAGE1  will  operate 
in  a foraatted  aode.  TPPAGE1  will 
then  support  the  3277  light  pen, 
function  key.w  and  3284/3286 
printers.  The  24th  and  last  line  on 
the  CRT  will  be  as  follows: 

2 0N£Zl__0NLZ2__0£P/3__2PLZii__2S/5__0H/6_0E/2__0P/8 

The  cursor  will  be  placed  in  the  2nd 
position  of  the  line  to  allow  key- 
board entry  of  coaaands.  The  next 
eight  fields  of  the  last  line  are 
selector  pen  detectable,  and  will 
cause  the  appropriate  function  to 
take  place  when  selected.  The 
nuaber  following  the  «/'  indicates 
♦•he  function  key  to  be  depressed  to 
perform  the  selected  function.  The 
last  field  of  the  line  is  ,P/8*,  if 
this  field  is  selected  with  the 
selector  pen  or  function  key  8 is 
depressed  it  will  cause  the  current 
page  to  be  printed  on  the  3284/3286 
printer  associated  with  the  3277. 

VALID- xxxxxxxx  The  VALID  option  is  used  to  specify 
the  entry  point  name  of  the  optional 
installation  written  validation 
subroutine.  The  installation 

validation  subroutine  can  control 
the  rightful  access  to  the  TP 
terainal  devices  and  NIPS  data 
files.  The  installation  validation 
subroutine  will  be  linkedited  as 
part  of  the  generated  TP  Monitor. 
For  a complete  description  of  the 
optional  installation  validation 
subroutine,  see  section  7.14  of  this 
manual. 
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DVM  = 


IHQ  = 


ODEHK 


NO_ 

mhe  DVM  option  defaults  to  NO  which 
YES  indicates  that  TP  executes  in  a 

single  virtual  machine  environment. 
IF  DVM=YES  is  specified  TP  assumes 
it  is  operating  on  a CP/67  DVM  and 
will  accept  CP  commands  while  in  the 
NIPS/TP  problem  program  state. 


nn 

DASD 


It 

is  a 

BDA 

M data  s 

a lw 

ays  o 

pen 

for  TP  mon 

and 

whic  h 

is 

open  as  a 

eac 

h time 

an 

applicatio 

sta 

rted . 

An 

internal  ( 

may 

be 

gene 

rated  by 

num 

eric  v 

alue 

between  1 

The  IMQ  operand  defaults  to  DASD 
which  indicates  that  the  Input 
Message  Queue  is  a data  set  on  a 
direct  access  storage  device  (DASD)  . 

which  is 
jr  routines 
BSAM  data  set 
>rogram  is 
("incore")  IMQ 
specifying  a 
) and  99  as 
a value  for  IMQ.  The  value 
specified  determines  the  number  of 
incore  IMQ  lines  allocated  for  each 
terminal.  The  IMQ  is  then 
maintained  as  a number  of  core 
resident  arrays,  one  for  each 
terminal,  each  line  of  which  is  R0 
characters  in  width.  The  use  of  an 
incore  IRQ  eliminates  the  need  for 
I/O  buffers  and  the  execution  of  I/O 
function  that  would  be  required  for 
a disk  resident  IMQ,  thereby 
improving  query  response  time.  See 
section  7.1.1,  TP  Monitor,  for 
increased  core  requirements  with  an 
incore  IMQ. 


NO 


YES 


Th*»  ODHEK  option 
which  indicates  t 
for  FORMATTER  wil 
ODEWK=YES  is  spec 
workarea  per  ter 
500  bytes  of  this 


defaults  to  NO 
hat  no  TP  workarea 
1 be  generated.  If 
ified  a 544  byte  TP 
minal  is  generated, 
area  are  used  for 
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passing  parameter  information  from 
TP  application  programs  to 

FORMATTER,  40  bytes  are  used  for  the 
dynamic  specification  of  format  name 
by  TP  application  programs,  and  four 
bytes  are  reserved  for  future  use. 

o.  Specifying  Priori* y of  Local  Terminals  - Priority 
of  local  terminals  is  specified  by  the  PRTY  operand 
of  the  QTPDD  macro  that  defines  them.  Terminal 
priority  will  default  to  1 if  omitted. 

c.  Increasing  the  Number  of  2 260/22  50  Terminals  - For 
more  than  eight  2260  terminals,  a QTPDD  card  should 
be  added  for  each  eigh*  additional  2260s  reguired. 
Each  QTPDD  card  must  have  a 3-character  label  that 
corresponds  to  a DD  name  in  the  Monitor  execution 
deck.  To  add  12  more  terminals,  for  example,  two 
QTPDD  cards  are  needed  such  as: 

D61  QTPDD  TYPE=2260, UNITS=8 
D62  QTPDD  TYPE=2260, DNITS=4 

Increasing  the  number  of  2250  terminals  - the  2250 
terminals  supported  by  the  distributed  TPMON 
defined  in  the  generation  deck  by  QTPDD  macro  in 
the  fora: 

DD5  QTPDD  TYPE=2250 
D51  QTPDD  TYPE=2250 

Each  additional  2250  requires  a QTPDD  card  with  a 
unique  label  (i.e.,  D52,  D53,  D54) . These  labels 
will  be  the  DD  statement  names  defining  the  devices 
when  the  TP  -job  is  executed. 

d.  Eliminating  2250  and/or  2260 ^ Support  - To  eliminate 
2250  support,  remove  the  " DD5  QTPDD  TYPE=2250M  card 
from  the  TPHONGEN  job.  To  eliminate  2260  support, 
remove  the  "DD6  QTPDD  TYPE=2260,  UNITS=8"  card  from 
the  TPMOMGEN  job. 
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TPSUP  - Any  problem  programs  other  than  LIST  which 
are  to  run  under  the  Supervisor  must  be  included  on 
the  QTPPR0G1  card.  For  example: 

QTPPPOG1  QUIP, FMSODA, DUMP 

This  example  will  enable  the  Monitor  to  recognize 
the  -«Q , -*F  , and  -»D  commands  for  executing  QUIP, 
FMSODA , and  the  PUMP  programs  in  addition  to  -*L  for 
executing  the  LIST  program.  The  distributed  TPMON 
will  recognize  the  -*Q  command  for  QUIP,  -»F  command 
for  SODA,  and  the  *n  command  for  TP  dump. 

Any  Conversational  programs  other  than  PAGE1  which 
are  to  tun  under  the  Monitor  must  be  indicated  on 
a QTPPP0G2  card.  If  P AG  El  is  the  only 
conversational  program  to  run  under  the  Monitor, 
then  this  card  may  be  omitted  from  the  Monitor 
generation . 

Any  independent  graphic  routines  which  are  to  run 
under  TPMON  must  be  included  on  a Q^PPROGB  card. 
If  no  independent  graphic  routines  are  required, 
this  card  may  be  omitted  from  the  Monitor 
generation  deck.  Refer  to  the  "Terminal 
Processing"  manual  for  a description  of  independent 
graphics  routines. 

Note:  when  a terminal  user  requests  a program,  the 
requested  program  name  is  checked  against  tables  of 
allowable  program  names  in  th-e  following  order: 

1.  Monitor  functions  (RECORD, TIME, STOP, MTO) 

2.  Conversational  programs 
1,  Problem  programs 

4.  Independent  graphics  programs. 

It  is  only  necessary  for  the  user  to  enter 
sufficient  characters  for  the  input  name  request  to 
identify  the  program  desired.  In  general,  one 
character  will  suffice  to  identify  the  program. 
However,  assume  that  a user's  system  contains  two 
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programs  beginning  with  (for  example)  the  letter 
•Q'  - a problem  program  named  QUIP  and  an 

independent  graphics  program  name  QUIK.  If  the 
user  wishes  to  request  QUIK,  he  must  use  all  four 
characters  of  the  name  to  identify  the  program.  A 
program  request  of  Q,  QU,  or  QUI  would  always  cause 
QUIP  to  be  loaded,  since  the  problem  program  table 
is  searched  for  a matching  entry  before  the 
independent  graphics  program  table  is  searched. 

f.  Generating a Nogitor for BTAM Terminals  - To 

generate  a Monitor  which  will  support  remote  2260, 

2741,  3270,  and/or  1050  terminals,  several  cards 
need  to  be  added  to  the  Monitor  generation  deck: 

o QTPDD  - Additional  QTPDD  cards  are  necessary 
for  BTAM  terminal  support.  Its  format  is 
described  below: 

ddname  QTPDD  UNITS=n,LINES=n,PRTY3[n  ], 

t ( n 1 , n2. .)  ] 

T YPE=[  22  60  ],PRINTER=name, 

[2250  ] 

[ PRINTER  ] 

( (BTAf1[  , ] ) ] 

[ , LOCAL] 

[ « BSC  ] 

[ .ASCII  ] 

NAMES3  ([  pollid  ], name,[  pollid  ],name..) 

[hex  addr]  [hex  addr  ] 

ddname3  A 3-character  DD  name  that  corresponds 

to  a DD  statement  in  the  JCL  which  specifies  the 
UCB  address.  Name  must  he  unique.  If  QTPDD 
macro  is  being  used  to  generate  a BTAM 
type  ♦erminal,  as  opposed  to  a terminal  device 
supported  by  CAM,  an  associated  QTPLINE  macro 
with  +he  same  name  must  be  a part  of  the 
Monitor  generation. 

UNITS  3 The  UNITS  operand  indicates  the  number  of 

Unit  Status  Tables  which  are  to  be  generated. 

The  default  value  is  1. 
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PRTY  = 


TYPE  = 


The  LINES  operand  indicates  the  number  of 
line  addresses.  this  operand  is  designed 
to  be  used  at  installations  with  two  or 
■ore  28«Rs  all  on  separate  cables  and  each 
cable  having  a unit  address  on  the  same 
multiplexor  channel.  The  LINES  operand  is 
not  used  with  local  3270  support.  The 
default  value  is  1. 

A list  of  priorities  cor  responding 
to  the  local  termianls  identified  in 
the  NAHFS  parameter.  (Priority  of 
BTAM  terminals  is  assigned  by 
QTPLINE  macro.)  If  the  PRTY  operand 
is  omitted,  all  local  terminals 
identified  will  assume  default 
priority  of  1.  The  corresponding 
terminal  priority  for  an  omitted 
entry  within  the  sublist  will  assume 
default  value  of  1. 


The  type  of  terminal 


[ 2260 
[ 22  50 
[ PP INTER 
[ ( BT AN[  , 

[ , LOCAL 
[ ,BSC 
[ , ASCII 

2260 

2250 

PPINTER- 

BTAM 


] 

] 

] 

])  ] 

} ] 

] 

] 

Local  2260 
Local  2250 

3284/3286  printer  devices 
All  terminals  that  are  not 
supported  by  GAN;  specifically, 
remote  2260,  dialed  1050, 
nonswit.ched  2741  , local  and 
remote  32",7. 


Specifies  that  no  additional  line 
type  information  is  needed. 
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, LOCAL' 

Qualifies  BTAM 
a local  3270. 

terminal  type 

to 

be 

, BSC  ' 

Qualifies  BTAM 

terminal  type 

to 

be 

a remote 

3270  using 

EBCDIC 

transmission  code. 

.ASCII  = 

Qualifies  BTAM 

terminal  type 

to 

be 

a remote 

3270  using 

ASCII 

transmission  code. 

NAMES'  <(  pol lid], name,..  .} 

[hex  addr]. 

Pairs  of  entries  which  identify  a 
terminal  by  pollid  or  hex  address 
and  a unique  user-defined  terminal 
name.  NAMES'  is  an  optional 
parameter,  since  the  system  will 
assign  a default  name  in  the 
following  format: 

XXX  XXXX  X 

CTPDD  name  * QT PDD  'T,YPE=  ♦ suffix 

Exa  m pie: 

DP6  QTPPD  TYPE=2260,UNTTS=2 
system  generated  names  - 
DD62260A.PD62260B 

For  local  2260,  2250,  and  BTAM 

terminals  types  of  2741  and  local 
3 27  C,  the  hex  add ress  is  paired  with 
the  user-assigned  name.  "‘he  user- 
ass  signed  terminal  name  may  be  a 
maximum  of  eight  characters. 

Example : 

DD5  QTPDD  TYPE=225C, NAMES' (03F, A2250) 
DD2  QTPDD  T YPE'2 2 60, UNITS=2 , 

NA«ES= (020,A2260,021,B2260) 

DD3  Q^PDD  TYPE' (BTAM, LOCAL) , 

NAMES' (310, A3270) 


56 


INSTALLATION 


PRINTER  = 


DP4  QTPDD  TYPE=(BTAM,)  , 

NAMES= (046.A2741) 

For  BTAf.  terminals,  other  than  2741s 
and  local  3270  devices,  a po Hid  is 
paired  with  the  user-assigned  name. 

Example: 

REb  QTPDD  TYPE=BTAM, NAKES= (A0A0, 
A2260) 

PEI  QTPDD  tYPE=BTAt|,  NAM.FS  = (6215, 
FIRST) 

PS3  QTPDD  TYPS= (PTAM, LOCAL)  , 

NAMES-  (31  1 ,' A3 2 7 0) 

”32  QTP^D  TYPE=  (BTAM,  BSC)  ,1JNITS=  3, 
NAMES* (4040, A 3220, 4 0C2,  83270, 

40C 3,03270) 

R 3 3 QTPDD  TYPE* (BTAK, ASCTI , UNIT=4 , 
NAMES* (2020, 83270,204 1 ,8^270 , 
2042,03270, 2043,03270) 

Used  to  associate  3284/3286  printers 
with  the  3277  terniinal  display 
defined  in  this  QTPDD  macro.  The 
name  specified  is  the  user- assigned 
terminal  name  given  in  the  QTPDD 
macro  which  defines  t he  printer. 
t?or  local  printers,  a separate  QTPDD 
macro  is  used  to  define  the  printer 
device;  for  remote  printers,  the 
device  is  named  in  the  NAMES  entry, 
and  is  specified  as  the  associated 
printer  via  the  PPItlTEP  entry.  For 
exa  mple: 

P32  QTPDD  TYPE* PRINTER, NAMES*  (31 1,P3270) 
L32  QTPDD  TYPE* {B^An, LOCAL) , NAMES*  (310 
L3270)  , PPINTEP  = P 3270 
R25  QTPDD  Typp= ( 3T  AM, BSC)  , N AM  ES*  (4040, 

PI  3270,  4001  , P2  3270, 4 DC2, 
P7327D) , PPINTER=P33270 
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Exa  mples : 

Local  2260  Terminals: 

D20  QTPDD  PRTY=4,TYPE=2260 
D21  QTPPD  UNITS=3,TYPE=2260,NAMES=(021, 
A2 260, 02 2, B2260,023,C2260) 

Local  2250  Terminals: 

03 F QTPDD  TYPE=2250 

D5F  QTPDD  TYPE=2250, NAM ES= (05F, A 2250) 

Remote  2260  Terminals 

PE6  QTPDD  UNITS  = 2,'T'YPE=BTAM,NAMES=  (AO  AO, 
FIRST, A0 Al,  SECOND) 

PE7  QTPDD  TYPE= (B^AM, ) , NAMES* (A0A0, 
FIRST) 

■*050  Terminals 

RE1  QTPDD  UN ITS*  3 , m YP  E=  BT  AM 
RE2  QTPDD  UN  ITS =2 , TYPE=  (BTAM,) 


2741  Terminals: 

D47  QTPDD  TY PE=  BT A 0 , N A (1  ES=  (04 7,  A 274 1 ) 
D48  QTPPD  mYPF= (RT AM, ) 

Local  3270  Terminals: 

L32  QTPDD  TY P E* ( BT  AM, LOCAL) , NAMES*  (410 
A 3270) , PRINTEF=P3270 
L 3 3 QTPPD  TYPE= PR  INTER, NAMES= (41 1 , 
P3270) , UNITS* 1 

L37  QTPPD  TYPE* (BTAM, LOCAL)  , NAMES*  (213 
A3270,214, B3270,215,C3270) ,UNITS=3 

Remote  3270  Terminals: 

R 32  QTPDD  UN TTS  = 2 , TYPE*  ( BTA M , BSC)  , 
NAPIES=  (4040,  A 32 70, 4 0C3,B32  7 0) 

R 3 3 QTPDD  UN  ITS*  3 , T YP  E=  (BTA  M,  BSC)  , 


( 


f 

t 


. , ***•■ 
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NAMES  = (4040, A 3270,  40C 3 , B3 27 0, 4 0C4 , 
P 3270)  , PR  I NTER=P3270 
R34  QTPDD  TYPE= (BT AM, ASCII) ,UNIT=4, 

NAMES =(2020, A3270, 2041, B3270, 
2042, C3270, 2043, D3270) 

o QTPLINE  - There  should  be  a QTPLINE  card  for 
all  BTAM  supported  devices.  The  QTPDD  card 
and  associated  QTPLINE  card  must  have  the  same 
3-character  label  in  the  name  field.  This 
label  must  consequently  appear  as  the  DD  name 
for  the  DD  card  defining  remote  units  in  the 
monitor  JCL.  (See  section  on  TP  Procedures.) 

The  format  is  described  below. 


j 

| 

| 

I 


T 


ddname  QTPLINE  ([  pollid  ],  name[  , pollid  ], name. ..)  , 

UCB  = hex  addr , PRTY=[ n ], 

[ (n1,n2, . . • ) ] 

TYPE=(device  t ype[  , mode  ][,  keyboard  arrangement] 

[, printer  device  ] 

[ , BSC  transmission  code]) 

ddname  = Must  be  same  3-charac+er  name  as 
appears  in  QTPDD  statement  which 
identified  the  unit. 

([  , pollid],  name{  .pollid  ], . . . ) = 

Pairs  of  entries  which  identify 
by  polling  ID  and  unique  user- 
defined  terminal  name.  This 
must  be  the  first  operand 
following  the  QTPLINE  operation 
code.  The  terminal  name  is  1- 
8 characters. 

Eor  2260s,  the  polling  ID 
consists  of  a 4-hex  digit;  the 
last  two  digits  will  be  A0,  Al, 

A 2 , ...  etc. 

Example;  (A0 A0, *IRST,  A0A1 .SECOND) 

Eor  1050*s  the  polling  ID 
consists  of  a 4-hex  digit;  the 
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last  two  digits  will  be  15. 

Since  only  one  1050  may  use  the 
line  at  a time,  several 
terminals  may  share  the  same 
line  ID. 

Example:  (6  215,  FIP  S'" , 6 2 1 5,  S ECOND, 

62  1 5,  TH I PD) 

For  2741  terminals,  the  polling 
TD  may  be  omitted  since  only 
one  terminal  may  be  attached  to 
a communication  line. 

Example:  (,A274l) 

For  local  7270  terminals,  the 
polling  ID  may  be  omitted, 
since  a relative  line  number 
for  each  3277  associated  with 
the  QTLI NE  macro  will  be 
automatically  generated. 

Example:  ( , A 3 270 , , B3270 , , C3270) 

por  remote  3270  terminals,  the 
polling  ID  consists  of  2 
hexadecimal  digits  in  EBCDIC  or 
ASCII  *o  represent  » he  control 
unit  and  device  addresses. 

Example:  EBCDIC 

(4  040, A 3 270, 40C2, B32  70, 40C3, 

C3270) 

ASCII 

(2020,A3270,2041,B3270,2042,C3270) 

(JCB  = hex  addr  Hex  address  which  identifies  the 
specific  line.  "lay  be  a list  of 
addresses  for  the  actual  lines  that 
the  polling  list,  is  to  be  used  for. 

For  local  3270s,  the  hex  address 
must  contain  the  address  of  the 
first  local  3277  assigned  to  the 
line. 


I •'••  •« 
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PRTY  = n 
(n  1 , n 2. .) 

The  list  of  priorities  corresponding 
to  the  terminals  identifies  in  the 
poll  list  parameter.  If  the  PPTY 
operand  is  omitted,  all  terminals 
identified  will  assume  default 
priority  of  1.  The  corresponding 
terminal  priority  for  an  omitted 
entry  within  the  subset  will  assume 
default  value  of  1.  Three  terminals 
with  respective  priorities  of  5,  1, 

and  6 could  be  coded  as: 

P P. T Y = (5, ,6)  or  PRTY=  (5,  1,6) 

TYPE  = (device  + ype[  , mode  ][, keyboard  arrangement] 

[, printer  device  ] 

Note:  The  subparameter  for  the  TYPE  keyword  are 
positional  in  nature.  The  absence  of  a positional 
parameter  is  indicated  by  a comma  coded  in  its 
place. 

f ,BSC  transmission  code]) 

Device  type  identifies  a particular 
type  of  device.  Possible  entries  are 
2260 
1050 
2741 
3270 

Mode  identifies  the  mode  in  which 
the  device  is  being  operated. 
Possible  entries  are: 


DIAL 

applies 
onl  y 

to 

1050 

devices 

LOCAL 

applies 

only 

to 

3270 

devices 

REMOTE 

applies 

only 

to 

3270 

devices 
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Keyboard  arrangement 
keyboard  arrangement 
designated  2741  device, 
entires  are: 


identifies 
for  the 
Possible 


Standard  IBH  Selectric  typewriter 
PTTC/BCD  code  compatibility 
PTTC/EBCD  code  compatibility 


Printer  device,  if  present, 
identifies  the  existence  of  a 
7284/3286  printer  device  on  the 
line,  and  causes  the  inclusion  of 
the  printer  I/O  appendage  and  entry 
point.  The  format  of  the  entry  is: 


[pRINTEp] 


BSC  transmission  code  identifies  the  remote 
3270  transmission  code.  Possible  entries  are: 


ASCII 

EBCDIC 

Examples 

2260  Terminals: 

RE6  QTPLINE  ( AO  AO , FIRST , AOA 1 , SECOND)  , 
(ICB=0  2F,PRTY  = (5,4)  ,TYPE=2260 

RE7  QTPLINE  ( AO  AO  , PIRST)  , IJCB=02  P , 
TYPE=2260 

1050  Terminals: 

PEI  QTPLINE  (6215, FIRST, 6235, SECOND, 

621  5,  THIRD)  , UCB=02 1 , TYPE=  (10  50,  DIAL) 

PE  QTPLINE  (6215, FIRST, 6215, SECOND)  , 
UCB=021 ,PRTY= (, 4)  , T Y P E- (1050, DIAL) 
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2741  Terminals: 

D47  QTPLINE  ( , A 27 4 1 ) , UC B = 047, PP T Y = 5 , 
TYPE=  (2741, ,S) 

D4B  QTPLINE (, A2741) ,UCB=04B, 

T YPE=  (2741  , , R) 

1270  Terminals- Local: 

L32  QTPLINR  ( , A 3 2 7 0) , UCP  = 4 1 0 , PPT Y = 4 , 

T YPE= (3270, LOCAL) 

L33  QTPLINR  ( , P 3270)  , TJC  B=  41  1 , T Y P E = ( 32 7 0 , 
LOCAL, PRINTEP) 

L37  QPTLINE  ( , A3 270 , , B3 270 , ,C3 2 7 0) , 

0CB=2 13 , TYPE  = (3270, LOCAL) 

3270  Terminals-Remote: 

R32  QTPLINE  (4040, A3270, 40C3,  B3270)  , 

tJCB=0  25,PPTY  = 4,TYPE  = (3270,  RENOTE,  , 
EBCDIC) 

P 3 3 QTPLINE  ( 404 0 , A32 7 0 , 40C 3 , B 3 27 0 , 40C4 , 
P3270) , UCB=025,TYPE=  (3270, REHOTE, 
PRINTER , EBCDIC) 


QTPPROGl  name, name, name,  .. . 

This  macro  is  used  to  identify  all 
the  problem  programs  which  are  to  be 
run  under  TP  Supervisor.  The  name 
operand  is  any  TP  problem  program 
name  other  than  LIST  which  is  run 
under  the  Supervisor,  so  that 
Monitor  will  recognize  control 
commands  for  executing  the  program. 
Names  must  be  six  characters  or 
less. 

Possible  entries  are: 

QUIP 
QUIP  VS 
PHSODA 
EDIT 
DUMP 
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VIEW 

ODE 

BLAST 

ACCESS 

RECORD 

X$$$ 

NOTE:  MTO  STOP  and  TINE  are  Monitor 
functions  and,  therefore,  not  listed 
under  problem  program  definition. 
Either  QUIP  or  QtllPVS  may  be  used  to 
identify  the  QUIP  component.  QUIPVS 
indicates  that  the  QUIPVS  load 
structure  is  to  be  used  for  QUIP 
applications  (see  section  7.15 
TPQUIPVS  Load  Structure  for  QUIP). 
If  TPQUIPVS  is  specified  as  the 
program  name  on  a QTPSPGM  macro  in 
the  TP  Supervisor  generation,  then 
QUIPVS  must  be  specified  here  on  the 
QTP  PROG 1 macro.  If  TPQUIP  is 
specified  in  the  TP  Supervisor 
generation,  then  QUIP  must  be 
specified  here  on  the  QTPPF0G1 
macro. 

QTFPR0G2  name, name, 

The  QTPPR0G2  macro  specifies  the 
names  of  conversational  programs 
other  than  PAGE  1 which  are  to  run 
under  the  Monitor.  If  PAGE1  is  the 
only  conversational  program  to  run 
under  the  Monitor,  then  this  macro 
may  be  omitted  from  the  Monitor 
generat ion. 

QTPPR0G3  name, name . 

The  QTPPR0G3  macro  specifies  the 
name  of  independent  graphic  routines 
which  are  to  run  under  the  Monitor. 
If  no  independent  graphic  routines 
are  required,  the  macro  nay  be 
omitted  from  the  Monitor  generation. 
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g.  Assigning  Type  III  SVC  Number  Other  than  SVC  240 

Change  the  3-digit  SVC  number  after  the  equals  sign 
in  the  QTPGEND  macro  which  has  the  form: 

QTPGEND  SVC=  240 

Tins  is  not  a zoned  SVC  number.  Do  not  change  the 
order  of  the  cards  in  the  TPMONGRN  deck.  The 
QTPGEND  macro  must  be  the  card  before  the  END 
TPMCTRL  card.  The  SVC  parameter  is  not  required  in 
an  MVS  environment. 


The  following  is  a sample  deck  for  generating  a Monitor. 


//TPMONGEN 

JOB 

// 

EXEC  A 

3MFCI., PAPM. ASM  = (LO A D, NODFCK ) , PARM . LKED=M AP 

//ASN.SYSLIB 

DD 

/✓ 

DD  DISP*SHR,DSNAME=PFS. JOB MACRO 

//ASM , S Y S IN 

DD 

* 

QTPMOPT  ACCTNG= YES 

DD5 

QTPDD 

T YP  E=2250 

D51 

QTPDD 

TYP  E=225C 

DDo 

QTPDD 

TYPE=22  60,(JNITS=8  , NAMES  = (1  30  , LEFT226  0 ,131  , 
FGTH2260) 

D61 

QTPDD 

TYPE=2260fUNITS=5 

RE  1 

QTPDD 

0NITS=3 

PE6 

QTPDD 

UNTTS=2 

R025 

QTPDD 

tJNITS  = 2, NANES= (4 04 0 , TER MOOOO  , 

40C3  ,PRINT000)  ,TYPE‘=(BTAM,BSC)  , 

PPINTER= (PHINT000) 

PEI 

QTPLIN 

E (6215,A1050,B1050,C105O) ,TY PE= ( 10 50 , DI AL) 

UCB=021 

REb 

QTPLTNE  (A0A0, A2260, A0A1,BZ260) ,TYPE=2260, 

OCB=02  F 

R025 

QTPLIN  E (4040,TERMOOOO,40C3,PPTNTOOC)  , 

TY  PE= (3270, REMOTE, PRINTER, 

EBCDIC)  , UCB=025 

QT  PFPOG1  Q'lIP,  FHSODA,  AS$$J 

QTPPROG3  GGINTFAC 

QTPGEND  SVC=240 

END 

X 


/* 

//LKED.S YSLMOD 
//LKED. SYSLID 


DD  DISP^OLD,  DSNAME=FFS. J03LIB (TPMON) 
DD  DTSP=SHR,DSNAME=SYS1.?ELCHLIB 


!. 
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//  DD  DISP=SHR, DSNAME^FFS. JOBLIB 

//LKSD.SYSIN  DD  * 

ENTRY  TPM  CTRL 
NAME  TPNON  (R) 

The  first  three  cards  in  this  example  need  never  be 

al eered. 

The  fourth  card  is  simply  the  second  in  a string  of 
concatenated  DD  cards  used  for  overriding  the  SYSLI9  DD  card 
in  the  assembly  step.  The  DSNAME  parameter  should  point  to 
the  system  data  set  containing  the  macros  necessary  for 
Monitor  generation. 

The  QTPMOPT  card  is  used  to  specify  to  the  TP  Monitor 
that  installation  accounting  data  is  to  be  provided.  For 
further  information  on  this  data,  see  the  section  - TP 

Accounting  Data. 

Cards  DD5,  D51,  DD6,  and  D61 , each  containing  the  QTPDD 

macro,  are  used  to  specify  that  this  Monitor  is  being 

generated  to  support  two  2250s  and  13  local  2260's.  Since 
the  PRTY  operand  was  not  specified  on  the  statements,  all 
terminals  assume  the  default  priority  of  1.  The  names  DD5, 
DD51,  DD6,  and  D61  must  appear  as  DD  names  for  the  specified 
units  in  the  Monitor  execution  deck. 

The  last  operand  on  the  QTPDD  card  - DD6  - is  used  to 
assign  names  to  the  hex  addresses  of  two  of  the  local  2260s. 
The  other  local  2260s  will  receive  their  names  through  the 
default  option  (see  TPSUP  Variations) . This  operand  takes 
the  form: 

NAMES= (XXX, OS ERN AM E, X XX, USERNAM. . .) 

where  XXX  is  the  hex  address  for  a 2250  or  local  2260.  Each 

hex  address  is  followed  by  the  name  to  be  assigned  to  that 

device.  When  making  use  of  this  option,  the  user  must  be 
certain  that  for  each  named  unit  there  exists  a 

corresponding  output  queue  named  •T.terminalname* . 

Refer  back  to  the  TP  Installation  section  for  a 

discussion  on  TERNINALNAHE. 
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The  QTPDD  cards,  REl  and  RE6,  together  with  their 
corresponding  QTPLINE  cards  are  used  to  indicate  remote 
support  consisting  of  three  1050s  and  two  2260s.  Since  the 
PPTY  operand  was  not  coded  on  the  QTPLINE  cards,  all 
generated  remote  1050s  and  2260s  assume  the  default  priority 
of  1.  The  names  PEI  and  RE6  must  appear  as  the  DD  names  for 
the  DD  cards  allocating  the  remote  units  in  the  Monitor 
execution  deck.  (See  section  on  TP  Procedures.) 

The  QTPDD  card  R025,  together  with  the  corresponding 
R0 25  QTPLINE  card  is  used  tc  show  how  3284/3286  printers  are 
defined,  and  then  associated  with  3277  terminals.  The 
printer (s)  defined  by  the  QTPDD  macro  is  associated  to  the 
terminal  defined  by  the  QTPDD  macro,  by  the  parameter  (s)  of 
the  PRINTER  operand.  The  QTPLINE  macro  includes  the  I/O 
appendages,  TPBT327 R and  TPBT328R,  and  their  entry  points  to 
be  used  by  the  line.  The  printers  and  terminals  will  be 
defined  through  a DD  card  which  associates  the  label  R025  to 
the  label  on  the  QTPDD  and  QTPLINE  macros. 

The  QTPPROG1  card  lists  the  programs  (other  than  KTO  and 
LIST  which  are  automatically  included)  that  are  to  run  under 
the  Supervisor.  The  ASSSS  is  used  to  illustrate  that  TPWON 
can  be  generated  with  space  names  for  unused  characters  such 
as  -«A. 

These  names  take  the  form  A$$$$,  The  TPSUP, 
which  actually  loads  the  problem  programs  and  graphic  jobs 
from  the  library,  can  be  given  the  correct  name  at  execution 
time  on  its  SYSIN  parameter  cards  (see  TPSUP  Variations)  . 
For  example: 

PROGLIST=USE  TPANAHE  TPQUIP  TPLISTl  TPPHSODA 
GGINTFAC. 

would  supply  a library  name  of  TPANAHE  to  use  instead  of 
TPA$$tS,  whenever  -«A  was  entered. 

The  other  names  are  required,  since  the  USE  card  must 
identify  all  programs  executable  within  a given  TPSUP 
region. 

The  only  conversational  program  to  run  under  this 
monitor  is  TPPAGE.  Since  this  is  automatically  included,  no 
QTPPROG2  card  is  used. 
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The  QTPPROG3  card  is  included,  however,  since  the 
independent  graphic  routine  GGINTPAC  is  to  be  run  under  the 
generated  Monitor. 

The  QTPG END  card  assigns  the  nunber  240  to  the  Type  III 
SVC  needed  for  the  Monitor.  This  must  be  the  last  card 
before  the  END  card. 

The  last  card  in  the  input  stream  is  the  END  card  which 
indicates  the  end  of  assembly. 

The  last  four  JCL  cards  in  the  deck  are  concerned  with 
the  link  edit  step  of  Monitor  generation.  These  cards 
should  appear  in  the  order  cf  the  DD  statements  in  the  ASHFC 
procedure.  The  DSNAHE  parameter  on  the  SYSLMOD  card  points 
to  PFS.JOBLIB  which  is  to  contain  the  generated  TPHON.  The 
DSNAME  parameter  on  the  SYSLIB  card  points  to  SYS1 . TELCMLIB; 
which  contains  the  LOPEN  routines  for  3270  devices  and 
FFS. JOBLIB  which  contains  the  component  TP  modules  for  the 
monitor.  The  SYSIN  statement  indicates  that  the  linkage 
editor  control  cards  follow  in  the  input  stream. 


7.5  TP  Supervisor  Generation 

Generation  of  TPSOP  involves  specifications  of  macro 
statements  in  the  TPSlJPG EN  job,  then  executing  it.  Two 
macros,  Q TPS  PGM  and  QTPSOPT,  may  be  used  to  create  the 
program  name  table  and  specify  the  control  options  used  by 
the  Supervisor.  The  program  name  table  is  a list  of  the 
programs  which  can  be  executed  by  the  TP  Supervisor,  and  the 
attributes  of  each.  The  generated  program  name  table  can  be 
modified  at  TPSOP  execution  time  by  using  the  PROGLIST 
statement,  described  in  section  7.6,  TP  Supervisor 
Variations.  The  FFS.JOBLie  contains  all  programs  necessary 
to  regenerate  a TPSOP.  Error  conditions  produced  during  TP 
Supervisor  generation  are  described  in  section  7.10  of  this 
document. 

a.  Build  the  program  name  table,  using  the  QTPSPGH 
macro.  One  QTPSPGH  macro  is  required  for  each 
program  other  than  the  TPLIST1,  TPDOHP,  GGINTFAC 
programs  (which  are  automatically  generated  into 
the  name  table  with  the  first  occurrence  of  a 
QTPSPGH  macro) . The  format  is: 
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QTPSPGM  prognaae, (attrib1,attrib2. 


, SFDSN 


The  prograa  name  is  required  as  the  first  operand. 
For  the  QUIP  component,  either  TPQUIP  or  TPQUIPVS 
■ay  be  specified  (see  section  7.15,  TPQUIPVS  Load 
Structure  for  QUIP).  However,  the  name  must 
correspond  to  the  one  specified  on  the  QTPPROGl 
■aero  in  the  TP  Monitor  generation.  If  QCIPVS  is 
specified  on  the  QTPPFOGl  macro  in  the  TP  Monitor 
generation,  TPQUIPVS  must  be  the  program  name  on 
the  QTPSPGM  aacro  for  the  QUIP  component.  If  QUIP 
is  specifed  on  the  QTPPFOGl  aacro  in  the  TP  Monitor 
generation,  TPQUIP  must  be  the  program  name  on  the 
QTPSPGM  aacro  for  the  QUIP  coaponent.  The  second 
operand  is  coded  within  parentheses  and  specifies 
attributes  from  the  following  list: 


OMQ  - 

INI  T - 

SIGN1  - 

SIGNHLT  - 

INDGR  - 

INCORFFT  - 


the  output  message  queue  data  set  is 
used  by  this  prograa 

an  initializing  prograa  is  required 
(the  name  of  the  initializer  is 
TIxxxxxx  where  TPxxxxxx  is  the  na«e 
of  the  program) 

the  prograa  is  a Sign-on  prograa  and 
only  one  copy  of  the  program  will 
reside  in  core  no  matter  how  many 
terminals  request  the  prograa. 

the  prograa  is  a Sign-on  prograa  and 
a copy  of  the  prograa  will  be  loaded 
for  each  terminal  request 

the  prograa  is  an  independent 
graphic  routine 

Control  record  and  File  Format  Table 
(FFT)  information  is  maintained  in 
core  for  the  active  file  when  QUIP 
is  in  signon  mode.  This  option  is 
valid  only  for  the  QUIP  coaponent. 
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When  this  option  is  specified, 
faster  QUIP  response  tine  is 
achieved  for  files  processed  in 
signon  mode: 

1.  Control  record  and  PPT 
information  , are  saved  in  core 
so  that  these  file  records  are 
usually  processed  only  once,  at 
the  time  the  file  is  signed  on, 
rather  than  during  the 
translation  of  each  query. 

2.  Field  label  and/or  edit  mask 
information  is  not  maintained 
in  core  but  is  obtained  from 
the  FFT  as  required  for  each 
query.  This  prevents  possible 
waste  of  large  amounts  of  core 
storage  since  label  and  edit 
mask  data  is  not  required  for 
the  majority  of  QUIP  operators. 

3.  When  a new  file  is  interrogated 
by  a user  running  in  sign-on 
mode,  required  information  from 
the  file  control  records  and 
the  fixed  information,  i.e., 
exclusive  of  label  and  edit 
mask,  from  the  File  Format 
Table  records  is  saved  in  ait 
area  which  is  made  available  to 
all  potential  QUIP  users  of  the 
file.  This  information  is 
available  as  long  as  there  is 
an  active  user  for  that  file  in 
the  TP  system. 

4.  if  the  user  is  signed  on  to 
another  file  at  the  time  the 
new  file  is  referenced,  the  PFT 
and  control  tables  for  that 
former  file  are  deleted, 
providing  no  other  QUIP  users 
are  signed  on  to  the  file.  If 
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other  QUIP  users  are 

signed 

on 

to  the 

file,  the 

tables 

are 

retained 

for  their  use. 

When  the 

user  signs 

off. 

the 

FFT  and  control  tables  for  the 
active  files  are  processed  as 
above  in  4. 

6.  Query  references  to  fields 
which  require  label  and/or  edit 
mask  information  are  processed 
by  accessing  the  FFT  record  for 
the  field  to  obtain  the 
required  information. 

When  the  INCORFFT  option  is  combined 
with  use  of  the  TPQUIPVS  load  module 
structure  (see  section  7.15, 

TPQUIPVS  Load  Structure  for  QUIP), 

QUIP  users  will  achieve  dramatic 
reductions  in  setup  time  when 
processing  signed  on  files.  QUIP 
setup  time  is  the  elapsed  time  to 
the  start  of  the  file  search. 

The  third  operand  is  valid  only  for  the  QUIP 
component. 

TERM 

SFDSN=  - Subfile  data  set  name,  the  two 

TEBP  alternate  name  formats  that  may  be 
assigned  when  the  QUIP  subfile  PDS 
is  allocated.  ’’'he  valid  keywords 
are: 

TJJRfl  _ Terminal  based  name, 
name  formatter  minalid . nnnnnn 
example  - NBCSSC1 . 145258 

TEBP  - OS  based  name. 

name  format=STSnnnnn.Tnnnnnn .RVOOO.jobname.SUBFIL 
example  - SYS76125.T152513. RVO 00. NIPSBTP. SUBFILE 
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TER M is  the  default  if  no  SFDSN 
parameter  is  coded. 

Note:  This  option  is  valid  only  for  QUIP. 

Note:  At  least  one  QTPSPGM  macro  is  required  in 
the  TPSUPGEN  job. 

Exaaple:  The  QTPSPGM  macro  statements  for  TPQUIP 
and  TPFMSODA , which  are  included  in  the  standard 
TPSUPGEN  job,  have  the  following  formats: 

QTPSPGM  TPQUIP,  (OMQ, INIT,S IGNMLT) 

QTPSPGM  TPFMSODA,  (OMQ, IN  IT , SIGN 1 ) 

TPQUIP  uses  the  output  message  queue  data  set,  an 
initializer  program  named  TIQUIP,  and  is  a sign-on 
program  type  of  which  one  copy  will  be  loaded  for 
each  request.  However,  since  the  load  module  is 
designated  as  reenterable  only  one  copy  of  the  load 
module  will  be  brought  into  main  storage  to  satisfy 
the  requirements  of  any  number  of  current  tasks. 
TPFMSODA  uses  the  Cutput  Message  Queue,  requires  an 
Initializer  program  named  TIFMSODA,  and  is  a sign- 
on  program  of  which  only  one  copy  will  be  loaded 
and  serially  reused  for  all  requests. 


Other  examples  of  the  QTPSPGM  aacro  are: 

QTPSPGM  TP  BL  AST 

QTPSPGM  TP  ACCESS,  (OMQ, SIGNMLT) 

QTPSPGM  TPCO  EDIT,  (SIGN1) 

QPTSPGH  TPEDIT,  (OMQ,  IN IT,S IGN 1) 

QTPSPGM  TPVIEH, (OMQ, SIGNMLT) 

QTPSPGM  TPODE, (OMQ, SIGNMLT) 

QTPSPGM  TPQUIPVS , (OMQ, INIT,S IGNMLT , INCORFFT) 
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This  example  shows  the  QTPSPOH  macro  when  the 
TPQUIPVS  load  structure  is  required  for  the  QUIP 
component  and  eontrol/PPT  information  is  to  be 
maintained  in  core  for  signed  on  files. 


Specify  the  TPSMP  options  using  the  QTPSOPT  macro, 
with  the  following  format: 


QTPSOPT 


PGPOUPS 


S I GNON= 


NOLOCK 

LOCK 


2S[ 

,0SEV3N*< 

vs[| 

(mj 

, DY  NA  MNT= { 

, S U9T A 5 K= 

| Y£S 

i 

(no  J 

__ 

[ NO 

E 


, ALTIO=namej 


The  operands  are 
_3 

EXTP  A=iin 


keywords. 

as  folio 

ws : 

where  n 

is  t he 

number  of 

empt  y 

entr ies 

to  be 

added 

to  the 

program 

name 

table. 

The 

default 

value 

is  EXTRA3 

3.  The 

total  number  of 

entries 

in  the 

program 

name 

fable 

cannot 

exceed 

1W. 

NOLOCK 

SIGNON=  The  "lockout"  option  (SIGNON= 

LOCK  LOCK)  specifies  that  requests 

for  major  programs  will  be 
denied  when  a Sign-on  program 
is  in  core.  Requests  for  the 
minor  programs  (TPLIST1, 

TPDUBP)  will  not  be  denied. 
All  other  programs  are 
considered  major  programs. 
This  message  will  be  displayed 
when  major  program  requests  are 
denied  — "XXXXXXXX  IS  SIGNED 
ON  AND  IS  THE  ONLY  HAJOR 
PPOG  RAN  WHICH  HAY  CUPPENTLY  BE 
RUN."  The  default  value  is 
SIGNOM=NOLOCK,  in  which  case 
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DYN ANNT= 


IIS 

NO 


SUBTASK= 


III 

NO 


_1 

PGROUPS=n 


TPSUP  will  attempt  to  honor  all 
program  requests. 


The  default  value  is  DYNANNT= 
YES,  in  which  case  the  system 
calls  for  a mount  of  user- 
requested  files,  on  the  unit 
allocated  to  the  DATAFILE  DD 
card.  If  DY  NAH  NT  = NO  is 

specified,  no  dynamic  mounting 
(on  the  unit  allocated  to 
DATAFILE  DD  card  in  the  TPSUP 
cataloged  procedure)  will  be 
done . 


The  default  value  is  SUBTASK=YES , 
in  which  case  the  system 

assumes  subtasking  to  be 
available  and  uses  the  ATTACH 
macro  for  linking  to  problem 
programs.  SUBTASK=YES  should 

always  be  coded  for  the  HVT 
environment.  YES  or  NO  may  be 
coded  for  the  HFT  environment 

without  the  subtasking 

capability.  SUBTASK=NO  should 
be  coded  for  the  HPT 
environment  with  subtasking 
capability  if  multitasking  is 
not  desired  within  the  TP 
system . 


Where  n is  the  number  of 
priority  groups  desired.  The 
digits  1,  2,  and  3 are  valid. 
See  the  section  entitled  Time- 
Slicing  for  a full  discussion 
of  priority  groups. 
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Identifies  the  TP  operating 
system  environment.  The 

default  value  is  OS.  OSEVRN=VS 
is  specified  when  the  operating 
system  environment  is  VS 2, 
release  2 or  later  (t*VS)  . 

Indicates  that  a user  written 
file  access  routine  with  the 
specified  name  is  to  be  used  by 
QUIP  to  read  file  data  records. 

The  routine  must  be  included  in 
the  library  specified  on  the 
STEPLIB  DD  statement  in  the  TP 
JCL.  This  function  was 
developed  for  a special 
application  and  is  not  designed 
for  general  use. 

Note:  Exactly  one  QTPSOPT  macro  statement  is 

required  in  the  TPSUPGEN  job,  even  if  all  default 
values  are  taken.  It  must  be  coded  after  the 
QTPSPGM  macro (s) . 

Example: 

QTPSOPT  EXTP A=5, SI GN ON=LOC K ,D Y NA MNT= NO, SU BT ASK=NO 

Pive  extra  entries  in  the  program  name  table  will 
be  generated,  the  "lockout1*  option  for  Sign-on 
proqrams  will  be  generated,  and  no  dynamic  mounting 
will  be  performed. 

The  following  is  a sample  deck  for  generating  a TP 
Supervisor  similar  to  the  distributed  TPSUP. 

//TPSUPGEN 
// 

//ASH.S YSLIB 
//ASB.SYSIN 


ASMFCL, PARN. AS M= (LOAD, NODECK) , P AFM. LK ED=K AP 


JOB 
EXEC 
DD 

DD  DISP-SHP, DSNAME=FES. JOBS ACFO 

DD  * 

QTPSPGK  TPQUTP,  (0  HQ.INIT,  S IGNHL’*') 
QTPSPGH  TPEHSODA,  (ONQ , INIT ,S IGN 1 ) 
QTPSPGH  TPB1AST 


OS 


OSE VRN= 


VS 


ALTIO=name 
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QTPSPGM  TPACCESS,  (SIGNHLT) 
QTPSPGM  TPCOEDIT , (SIGNl) 

QTPSPGM  TPEEIT, (OMQ,INIT,SIGNl) 

QTPSOPT  DYNAHNT=NO 

END 


/* 

//LKED.S YSLIB  DD  DISP=SHF,  DSNAME=FFS. JOB LIB 

//LKED. S YSLMOD  DD  DISP=OLD, DSNAHE=FPS . JOBLIB (TPSOP) 
//LKED.SYSIN  DD  * 

ENTRY  TPSUPEX 
NAME  TPS U P (R) 


The  first  three  cards  in  the  above  exaaple  need  never  be 
Modified. 

The  fourth  card  overrides  the  assembly  step  to 
concatenate  the  systen  data  set  containing  the  aacros 
necessary  for  TPSOP  generation. 

The  QTPSPGM  cards  in  the  input  strean  add  TPQOIP, 
TPFHSOD A,  TPBLAST, TPACCESS,  TPCOEDIT,  and  TPEDIT  to  the 
prograa  naae  table,  and  specify  the  progran  attributes. 

The  QTPSOPT  aacro  state aent  adds  three  extra  entries  to 
the  prograa  naae  table  taken,  and  establishes  no  dynaaic 
aounting.  The  lockout  option  is  not  generated  in  the 
standard  TPSOP.  Exactly  one  QTPSOPT  aacro  aust  be  included 
in  the  input  strean,  and  it  aust  follow  the  QTPSPGM 
aacro  (s)  . 

The  last  card  in  the  input  strean  is  the  END  card  which 
indicates  the  end  of  asseably.  It  aust  follow  the  QTPSOPT 
aacro  statenent. 


The  last  three  cards  in  the  TPSUPGEN  job  apply  to  the 
link  edit  step  of  the  ASHFCL  procedure.  These  cards  should 
appear  in  the  order  of  the  DD  statenents  in  that  procedure. 
The  DSNAME  paraneter  on  the  S YSLMOD  card  points  to 
FFS. JOBLIB  which  is  to  contain  the  generated  TPSOP.  The 
DSNAME  paraneter  on  the  S YSLIB  card  points  to  the  data  set 
containing  the  conponent  TP  nodules  coaprising  the 
Supervisor.  The  SYSIN  statenent  indicates  that  the  linkage 
editor  control  cards  follow  in  the  input  strean. 
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7.6  TP  Supervisor  Variations 

The  TPSUP  may  be  modified  by  the  use  of  PROGLIST  and 
TERNLIST  statements  at  the  time  the  Supervisor  is  executed. 
This  is  done  by  overriding  the  SYSIN  DD  statement  with  a 

//TPSUP. SYSIN  DD  * 

DD  statement  followed  by  the  PROGLIST  and  TERHLIST 
statements. 

a.  PROGLIST  Statements  - The  PROGLIST  card  has  the 
following  formats: 

PROGLIST=ALL. 


progname  progname  progname. 

Any  number  of  program  names  may  be  listed, 
continuing  the  statement  in  column  1 of  successive 
cards,  ending  with  a period  after  the  last  name. 

The  PROGLIST  statement  indicates  which  of  the 
programs  generated  into  the  TP HON  name  table  are  to 
be  executed  under  TPSUP.  If  all  the  programs 
listed  on  the  QTPPROGl,  QTPPR0G2,  and  QTPPROG3 
cards  (see  TPHON  Generation)  are  to  be  marked 
executable,  no  PROGLIST  card  need  be  supplied  since 
the  default  is  PROGLIST= ALL. 

Variations  can  be  made,  however,  by: 

PROGLIST=USE  progname  progname. 
or 

PROGL I ST= DELETE  progname  progname. 

For  example: 

PROGLIST=DELETE  TPFMSODA. 

will  prevent  TPSUP  from  executing  a -»FH  reguest. 
The  program  name  is  the  full  library  name  (e.g., 
TPQUIP,TPHT01,TPLIST1)  including  the  *TP'  prefix 
supplied  by  the  Honitor. 


USE 

PROGLIST=  DELETE 
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TERHLIST  Statements  - The  TERHLIST  statement  has 
the  following  formats: 


TERHLIST= ALL. 
or 

USE 

TERHLIST=  [DELETEj  termname  termname, 


1 


TERHLIST  statements  may  contain  any  number  of 
terminal  names,  continuing  the  statement  in  column 
1 of  successive  cards,  ending  with  a period  after 
the  last  name. 

The  TERHLIST  statement  indicates  which  of  the 
terminals  made  available  at  Honitor  generation  time 
(see  TPHON  Generation)  are  to  be  serviced  by  the  TP 
Supervisor . 

Terminal  names  are  optionally  assigned  to  hex 
addresses  at  Honitor  generation  (see  TPHON 
Generation).  The  default  name  is  DDD22X0Z  where 
DDD  is  the  3-character  DD  name,  X is  five  or  six 
for  2250  or  2260,  respectively,  and  Z is  an  A for 
a 2250,  or  A,  B,  C,...  for  multiple  2260 
terminals  assigned  under  one  DD  card. 

If  all  the  available  terminals  are  to  be  serviced, 
no  TERHLIST  card  need  be  supplied  since  tfce  default 
is  TERHLIST=ALL. 


7.7  Hultiple  TP  Supervisors 

Hultiple  TP  Supervisors  are  no  longer  supported  under 
NIPS  Release  21.05. 


7.8  TP  Honitor/Supervisor  Advisory/Diagnostic  Hessages 

The  following  messages  are  issued  to  advise  the  console 
operator. 

TP  TERHINALS  OPEN  message  is  written  after  successful 
completion  of  terminal  initialization. 
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TP  STANDING  REQUEST.  REPLIES  ARE  'ENA',  ‘DISA*,  'MSG', 
' PET Y ' , 'TPS',  or  ' TPM ' . --Operator  can  ignore.  When  it  is 
desired  to  stop  TP  Supervisor  reply  TPS  to  cause  normal  end- 
of-job.  When  desired  to  stop  the  TP  application  entirely, 
reply  TPfl.  The  reply  ENA  is  used  to  place  a terainal  in  an 
active  status.  The  reply  DISA  is  used  to  place  a terainal 
in  an  inactive  status.  The  reply  MSG  is  used  by  the 
operator  to  send  messages  to  terminals.  The  reply  PRTY  is 
used  to  alter  terminal  priority. 


The  reply  options  to  the 
have  the  following  formats: 


\ 

R nn. 


f ALL 


ENA  < name 
DISA [ (namel 


naae2) 


NIPS/TP  outstanding  reguest 


Enable 

Disable 


(ALL  | 

name 

(namel  nane2)J 


text  of  aessage 


Message 


[all  I 

[l-15 

PBTY< 

name 

L < 

i EXPRESS 

[(namel  name2)j 

1 

1 

Priority 


TPS 


Cancel 

TP 

SUPERVISOR 


TPM 


Cancel 

TP 

MONITOR 

and 

SUPERVISOR 


TP  SUPERVISOR  READY  — Message  is  written  after 
successful  completion  of  TP  Supervisor  initialization. 


The  following  advisory  messages  are  issued  in  response 
to  the  operators  reply  to  the  NIPS/TP  outstanding  reguest: 
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5010  TP  MONITOR  HAS  TERMINATED  NORMALLY 

The  TP  Monitor  has  terminated  normally  as  the 
result  of  the  computer  operator  replying  TPM  to  the 
outstanding  TP  reply  ID.  The  UTTPDPVR  control 
program  mill  also  end  as  a result  of  this 
condition.  No  user  action  is  required. 

5020  TP  SUPERVISOR  HAS  TERMINATED  NORMALLY 

The  TP  Supervisor  has  terminated  normally  as  a 
result  of  the  computer  operator  replying  TPS  or  TPM 
to  the  outstanding  TP  reply  ID.  No  user  action  is 
required. 

5015  TP  MON  HAS  ABENDED.  S000  U0000. 

The  TP  Monitor  task  has  ABENDed  with  a S000  or 
U0000  error  code.  The  TP  Supervisor  task  will  be 
terminated,  and  both  TPMON  and  TPSUP  will  be 
automatically  restarted.  If  the  ABEND  persists 
contact  the  NIPS  Technical  Assistance  Group  for 
programming  support. 

5025  TPSUP  HAS  ABENDED.  S000  U0000. 

The  TP  Supervisor  task  has  ABENDed  with  a S000  or 
U0000  error  code.  The  TP  Monitor  will  be 
terminated  and  both  TPMON  and  TPSUP  will  be 
automatically  restarted.  If  the  ABEND  persists 
contact  NIPS  Technical  Assistance  group  for 
programming  support. 

3351 


5027 

TP  TERMINAL 

USERS  STILL  SIGNED  ON. 

SHOULD 

TP 

BE 

RESTARTED  - 

REPLY  YES  OR  NO. 

***  ACTION 

REQUIRED  BY 

OPERATOR  *** 

The 

TP 

Supervisor 

has  terminated 

as  a 

result 

of 

the 

computer  operator  replying 

TPS 

or  TPM 

to 

the 

outstanding  TP  reply  ID;  however,  terminal  users 
were  still  active.  The  operator  must  reply  with 
one  of  the  following  options: 
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YES  The  TP  Monitor  and  Supervisor  will  be 
restarted. 

NO  The  TP  tasks  will  come  to  a normal  completion, 
and  the  UTTPDRVR  program  will  end. 

The  following  diagnostic  messages  may  appear  on  the 
operators  console  any  time  during  NIPS/TP  execution: 

5027a 

5027B  NIPS  TP  LINE  ERROR.  NO  ACTION  REQUIRED. 

The  remote  3270  CRT  program  (TPBT327R)  has  detected 
error  conditions.  The  sense  and  status  message  has 
been  acknowledged,  and  the  failing  I/O  operation 
re-tried,  if  appropriate. 

5028  TP  MONTTOR/SOPERVISOP  ABEND.  M AXHAITS  VALUE 

EXCEEDED. 

The  TP  Monitor /Supervisor  task  has  ABENDed  with  a 
SOcI  because  the  number  of  multiple  wait  entries 
has  been  exceeded.  A high  level  of  system  activity 
caused  this  ABEND,  and  the  installations's  Systems 
Programmer  must  increase  the  number  of  wait  entries 
to  prevent  the  ABEND  from  reoccurring. 

The  following  steps  must  be  followed  to  increase 
the  number  of  multiple  wait  entries: 

1.  Increase  the  number  of  multiple  wait  entries 
in  the  QTPEQUS  macro.  The  default  value  in 
the  distributed  system  is  100  entries.  This 
value  must  be  increased  in  the  QTPEQUS  macro. 

2.  Assemble  and  linkedit  the  following  TP 
programs  using  the  revised  QTPEQUS  macro. 

TP ACCESS  TPSUPEX 

TPHLIST  TPSUPSTP 

TPPAGE1  TPSUPINI 

TPSUPCLP 

3.  Regenerate  the  TP  Monitor  and  Supervisor  using 
the  assemble  programs  from  step  2. 
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5029  INVALID  PARM  FIELD  FOP  UTTPDPVR 

The  TP  Driver  task  has  abnormally  terminated  due  to 
an  invalid  subparameter  that  has  been  specified  in 
the  PARM  field  cf  the  EXEC  statement.  The  valid 
PARM  entries  are;  TPHONxxx,  TPSUPxxx,  WORKUNIT=,  or 
TP=  (see  section  6.2  of  this  document  for  details). 
Correct  statement  and  reload  TP  job. 

During  the  initialization  of  TP  Monitor  and  TP 
Supervisor  the  following  advisory  diagnostics  may  appear  on 
the  operators  console: 

TP  MONITOR  NOT  INITIALIZED  — TPSUP  task  was  started 
before  the  TPHOM  task.  Reload  the  TP  job  and  wait  for  the 
message  TP  TERMINALS  OPEN. 

2250/2260  WRITE  ERROR,  IGNORED  — Operator  can  ignore. 
Repeated  occurrences  may  indicate  a need  for  IBM  CE 
attention  to  a problem  to  in  the  2250/2260  hardware. 

TPMON  SHOTTING  DOWN  32^7  LINE  XX  TERMINAL  XXXXXX  — TP 
Monitor  task  is  shutting  down  specified  3277  terminal  due  to 
repeated  I/O  errors. 

TPMON  UNABLE  TO  INITIALIZE  3277  LINE  — Operator  can 
ignore.  Diagnostic  message  is  generated  when  local  3277 
assigned  to  TP  job  is  switched  off  during  TP  Monitor 
initialization. 

TOO  MANY  TERMINALS  FOR  WAIT  LIST  — TEPMLIST  SYSIN  card 
assigned  more  than  99  terminals  to  this  TP  Supervisor. 
Reduce  the  number  and  reload  the  TP  job.  The  maximum  number 
is  99. 

INVALID  KEYWORD  IN  CONTROL  CARD  — SYSIN  card  does  not 
begin  with  TERHLIST  or  PROGLIST.  Correct  input  cards  and 
reload  the  TP  job. 

INVALID  ITEM  REQUESTED  - XXXXXXXX  — SYSIN  card 
contained  an  invalid  terminal  name  or  program  name,  where 
XXXXXXXX  is  the  name.  Correct  it  and  reload  TP  job. 


T 
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NO  STMT  T5RMIN  ATOP  ON  L AS’1’  CARD  --  SYSIN  card  has  no 
period  after  names  in  list.  Insert  period,  and  reload  TP 
job. 


BLBL  ERROR  --  I/O  error  while  searching  JOBLIB  directory 
during  TP  Supervisor  initialization.  Verify  that  data  set 
specified  on  JOBLIB  DD  s tatement  contains  all  the  named 
programs  and  reload  TP  job. 


7.  9 TP 
Code 


2000 


Nonitor/Supervisor  ABEND  Codes 
Explanation 


44 

Cause 

I/O  error  on  write  to  a remote  3284/3286  printer 

45 

device.  The  printer  device  may  require 

55 

operator  intervention  since  the  I/O  error  may 
be  caused  by  an  open  cover,  disable  status  or 
being  out  of  paper. 

. 

Action  - 

Check  printer,  if  error  persists  there  may  be 
a hardware  problem. 

301 

Cause 

An  ECB  already  has  a wait  bit  set  (System 

ABEND)  . 

f 

Action  - 

Cancel  TP  job  and  reload.  If  error 

persists  contact  NIPS  Technical  Support 

Group. 

776 

' Cause 

Error  in  initialization  of  TP  Supervisor. 

Action  - 

Message  is  on  console.  Correct  and 

reload  TP  job. 

1234 

1235 
1237 

Cause 

I/O/error  on  read/write  to  a local  3277 

CRT  device. 


Action  - 


Chech  CP T device,  if  error  persists  there 
may  be  a hardware  problem. 


Cause 


I/O  error  on  read/write  of  Input  Message 
Queue. 
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2004 

2008 

2012 

2016 

3000 


Action  - 

Cause 
Action  - 
Cause 
Action  - 
Cause 

Action  - 
Cause  - 
Action  - 
Cause  - 

Action  - 


Cancel  TP  job  and  reload.  If  error 
persists  scratch  the  disk  resident  IMQ 
and  reallocate. 

Unable  to  open  Input  Message  Queue. 

Cancel  TP  job  and  reload. 

I/O  error  formatting  Input  Message  Queue. 
Same  as  2004. 

Unsuccessful  SPAP  (Specify  Attention 
Routine. ) 

Same  as  2004. 

Unable  to  open  statistics  data  set. 

Same  as  2004. 

I/O  error  on  write  to  statistics  data 
set . 

Same  as  2004. 


"7.10  TP  Honitor/Supervisor  and  TPSVC  Generation 

Errors 

The  following  MNOTE  statements  are  produced  during 
generation  of  the  TP  Monitor,  TP  Supervisor  and  TPSVC. 

I1S1x-K2«.  SSJtSE  ill  S*£lanali2n 

100  8 QTPSOPT  SPEC I PI  ED  BEFORE  QTPSPGM 

Action:  Place  the  QTPSOPT  macro 

statement  after  the  QTPSPGM  macro, 
statement  and  rerun  the  job. 

101  8 MORE  THAN  ONE  QTPSOPT  SPECIFIED 

Action:  Do  not  include  more  than 
one  QTPSOPT  macro.  Rerun  the  job. 
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qsg.  No.  Severity 


Explanation 


102 


103 


104 


9 


8 


8 


106 


107 


108 


8 


8 


8 


110 


8 


ILLEGAL  SIGNON  OPTION 

Action:  Change  SIGNON=  to  LOCK  or 

NOLOCK  and  rerun  the  job. 

ILLEGAL  MOUNTING  OPTION 

Action:  Change  D YNAMNT=  to  YES  or 

NO  and  rerun  the  job. 

TOTAL  NO.  OF  PGMS  EXCEEDS  100 

Action:  Reduce  the  number  of  extra 

entries  for  the  program  name  table 
and  rerun  the  job. 

ILLEGAL  ACCOUNTING  OPTION 

Action:  Change  ACCTNG=  to  YES 

or  NO  and  rerun  job. 

ILLEGAL  FULLPAGE  OPTION 

Action:  Change  FULLPAGE  = to 

YES  or  NO  and  rerun  job. 

VALIDATION  ROUTINE  NAME  TOO  LONG 

Cause:  The  name  of  the  specified 
installation  validation  subroutine 
exceeds  8 characters  in  length. 

Action:  Correct  the  name  and 
rerun  the  job. 

ATTRIBUTE  IS  ILLEGAL  PARAMETER 

Action:  Verify  that  all  program 
attributes  are  spelled  correctly 
and  rerun  the  job. 
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«siii_Noi_  severity 


111 


112 


113 


114 


115 


12 


*■>  , r V 
« ' 

l 


Exnlanat ion 


ATTRIBUTE  IS  INCON SI STE N^  PAFAMETEP 

Cause;  The  specified  attribute  ar.d 
at  least  one  other  attribute  are 
mutually  exclusive. 

Action:  Correct  the  program  attri- 
butes and  rerun  the  job* 

NO  PARAMETERS  SPECIFIED 

Cause;  No  operands  are  coded  on  the 
QTPSPGM  macro. 

Action:  Specify  the  desired  program 

and  attributes  and  rerun  the  job. 

ONLY  ONE  PFOGRAM  REQUEST  PER  QTPSPGM 
MACRO 

Action:  Specify  the  desired  programs 

on  separate  QTPSPGM  macro  statements 
and  rerun  the  job. 

INCLUSION  OE  PGM  IS  AUTOMATIC, 

REQUEST  IGNORED 

Cause:  You  specified  TPLIST1,  TPM^OI, 

TPDUMP,  or  GGINTEAC  on  a QTPSPGM  macro 
statement.  This  macro  statement  has 
been  ignored. 

Action:  None. 

ILLEGAL  NUMBER  O”  IMQ  RECORDS 
SPECIFIED.  MUST  BE  B"  10/49. 

Cause:  An  incorrect  value  was 

specified  for  the  IMQ  operand 
of  the  QTPMOPT  macro.  The 
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Msg.  No.  Severity 


120  8 


121  9 


122  8 


123  9 


4 

I 


i 


Explanation 


value  was  not  DASD  nor  was  it 
a number  between  10  and  99. 

Action:  Specify  DASD  if  the 

IMQ  is  a data  set  allocated 
on  a direct  access  storage 
device.  Specify  a 2 digit 
number  between  10  and  99 
(inclusive)  to  indicate  the 
number  of  incore  IMQ  lines 
to  be  allocated  internally 
for  each  terminal  in  the  tp 
system . 

PRIORITY  EXCEEDS  RANGE 

Cause:  The  P°TY=  value  specified 

was  not  within  the  range  of  1 to  15. 

Action:  Change  PR?Y=  to  a valid 

priority  and  rerun  job. 

PRIORITY  OMITTED,  DEE  AULT  USED 

Cause:  PPTY=  was  not  specified. 

Action:  None  if  priority  1 is  desired. 

PGROUPS  VALUE  EXCEEDS  RANGE 

Cause:  The  PGROUPS*  value  specified 

was  not  within  the  range  of  0 to  3. 

Action:  Change  PGROUPS*  to  a valid 
value  and  rerun  job. 

PGROUPS  OPERAND  OMITTED  DEFAULT  TO 
ZERO  SUBSTITUTED 

Cause:  PGPOUPS*  was  not  specified. 

I 
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Msg . No.  Seve r ity  IIEl^nat ion 


124 


8 


125  9 


126 


0 


200  9 

201  9 


Action:  None  if  priority  groups  are 
not  desired. 

PRIORITY  ’sublist  entry'  EXCEEDS 
RANGE 

Cause:  The  PRTY=  sublist  entry  priority 
value  specified  was  not  within  the 
ra  lge  of  1 to  1 5. 

Action:  Change  the  entry  to  a valid 
priority  value. 

PRTY  • sublist  entry’  OMITTED,  DEFAULT 
USED 

Cause:  The  PPTY  sublist  entry  was 
not  specified. 

Action:  None  if  priority  1 is  desired. 

THE  REQUIRED  QTPSPGM  MACRO  OPTION (S) 
’option* , 

WERE  SET  FOP  COMPONENT  ’component  name*. 

Cause:  the  reguired  TP  Supervisor 
program  ’option (s) • were  set  for  the 
NIPS  component  specified  as 
'component  name'. 

Action:  None. 

2250  NFEDS  1 DD  PER  UNIT 

Action:  Change  UNITS=  to  1 and  rerun 

the  job. 

ILLEGAL  TYPE 

Cause:  Unsupported  terminal  type. 

Action:  Change  TYPE=  to  the  correct 
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"Sai-NO;.  Severity  Sx£lanation 


terminal  type  and  rerun  the  job. 

202  9 The  name  field  of  the  QTPDD  and/or. 

QTPLINE  macro (s)  which  is  used  to 
define  the  DONAHS  may  not  exceed 
three  characters  in  length. 

Cause:  The  name  field  (DDANHE 
specification)  on  the  QTPED  macro 
was  longer  than  three  characters. 

Action:  Specify  a DDNAHE  of  from  1 to 
1 characters  in  the  QTPDD  and  associated 
QTPLINE  macro  (s) . Note:  only  BTAH 
terminal  types  require  a QTPLINE 
macro. 

220  8 INVALID  CP67  OPTION  SPECIFIED 

Cause:  The  CP67=  entry  was  not 
valid. 

Action:  Change  CP67=  to  YES  or 
NO  and  rerun  job. 

221  9 INVALID  GAH2250  OPTION  SPECIFIED 

Cause:  The  GAH22S0  entry  was 
not  valid. 

Action:  Change  GAH2250=  to 
YES  or  NO  and  rerun  job. 
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7.11  TP  Accounting  Data 

The  TP  component  optionally  provides  accounting  and 
statistics  data  for  installation  use.  This  data  is  recorded 
in  a single  data  set  (defined  by  the  STATRECS  DD  statement 

in  the  TP  Job  Control  Language)  in  a format  suitable  for 

input  to  a NIPS  file.  The  NIPS. SAMPLE. JOB  library  contains 
a sample  job  (TPLOGJOB)  which  could  be  used  to  create  a NIPS 
file  from  this  data.  All  data  is  in  EBCDIC  and  can  be 

output  directly  to  a print  data  set  if  desired.  The 

accounting  output  directly  to  a print  data  set  if  desired. 

The  accountand  statistical  data  is  accumulated  from  the  TP 
Monitor,  TP  Supervisor  and  problem  programs  executing  under 
the  Supervisor. 

Accounting  and  statistics  records  are  recorded  for  the 
following  functions  as  they  occur  within  the  TP  Monitor  or 
TP  Supervisor  (s)  partitions: 

a.  Task  initialization  and  termination  of  the  TP 

Monitor 

b.  Task  initialization  and  termination  of  the  TP 

Supervisor 

c.  Terminal  operator  LOGON,  LOGOFF  and  REMARKS 
requests 

d.  Problem  program  initialization  and  termination. 

e.  Independent  graphics  program  initialization  and 
termination. 

f.  PAGE  program  initialization  and  termination. 


<10 


INSTALLATION 


7.11.1  TP  Monitor  Task  Initialization  Record 

This  record  is  output  during  the  initialization  of  TP 
Monitor  partition  as  follows: 


Record 

Positions 

1 

2-5 


6 

7-9 

1u 

11-13 

14 

15-19 

20-21 

22-26 

27 

28-33 

34 

35-42 

43 

44-51 

52 

53-60 

61-133 


field 

Terminal  address 

Component  Identifier 
Task  Identifier 
Start  Identifier 
Date 
Time 

Job  Name 
Step  Name 

Procedure  Step  Name 


Description/Content 

Blank 

TPM 

JOB 

START 

Date  in  format  TTDDD 
Time  in  format  HHMMSS 
Self-explanatory 
Self-explanatory 
Self-explanatory 
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7.11.2  TP  Monitor  Task  Termination  Record 


This  record  is  output  at  the  termination  of  the  TP 
system  (after  Supervisor  has  completed)  as  follows: 


Pecord 

Easitians 

field 

Descript ion /Content 

1 

2-5 

C . 

Terminal 

Blank 

O 

7-9 

Component 

Identifier 

TPM 

10 

11-13 

Task  Identifier 

JOB 

14 

15-19 

20-21 

Stop  Identifier 

STOP 

22-26 

Date 

Pate  in  format  YYDDD 

27 

28-33 

34-133 

Time 

Time  in  format  HHMMSS 

I 


92 


INSTALLATION 


7.11.3  TP  Supervisor  Task  Initialization  Record 

This  record  is  output  durinq  initialization  of  the  TP 
Supervisor  as  follovs: 


Record 


Eosition^ 

Description/Content 

1 

2-5 

Terminal  Address 

B1  ank 

7-9 

Component 

Ident if ier 

TPS 

10 

11-13 

Task  Identifier 

JOB 

14 

15-19 

Start  Identifier 

START 

20-21 

22-26 

Date 

Date  in  format  YYDDD 

27 

28-3  3 

Tine 

Time  in  format  HHHNSS 

34 

35-42 

Job  Name 

Self-explanatory 

43 

44-51 

Step  Naie 

Sel f-explanat  or y 

52 

53-60 

Procedure  Step  Name 

Self-explanatory 

61 

b2-64 

Task  DPRTY 

TP  Supervisor's  dispatchinq 
priority. 

65-133 
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7.11.4  TP  Supervisor  Task  Termination  Pecord 

This  record  is  output  by  the  TP  Supervisor  during 
termination  processing  as  follows: 

Record 

£osi tions  Field  Description/Content 

1 

2-5  Terminal  Address  Blank 

6 

7-9  Component 

Identifier  TPS 

10 

11-13  Task  Identifier  JOB 

14 

15-19  Stop  Identifier  STOP 

20-21 

22-2fa  Date  Date  in  format  YYDDD 

27 

28-33  Time  Time  in  format  HHMHSS 

34-133 


i 
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7.11.5  Terminal  Operator  LOGON  Pecord 

This  record  is  output  for  each  terminal  operator  LOGON 
request  in  a TP  environment  where  no  installation  validation 
subroutine  has  been  specified  at  monitor  generation. 

Record 


Positions 

Pield 

Description /Con tent 

1 

2-5 

Terminal  Address 

3-character  UCB  address 
for  local  terminal;  4- 
character  POLL  list  for 

remote  terminal 

7-9 

Component 

Identifier 

TPM 

10 

11-13 

LOGON  Code 

LOG 

14 

15-19 

20-21 

Start  Identifier 

START 

22-26 

Date 

Date  in  format  YYDCD 

27 

28-33 

34-35 

Time 

Time  in  format  HHMMSS 

36-45 

Account  Number 

10-character  LOGON  Account 
N umber 

4b 

47-5b 

User  ID 

10-character  LOGON  user  ID 

57 

50-61 

62-64 

Terminal  Priority 

Self-explanatory 

65 

66-133 

Comments 

LOGON  user  comments 
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This  record  is  output  for  each  terminal  operator  LOGON 
request  which  has  been  successfully  validated  by  optional 
installation  validation  subroutine. 

Record 


Eositiarjs 

Pield 

Description/Content 

1 

2-5 

Terainal 

3-character  tlCB  address 

Address 

for  local  terminal,  4- 
character  POLL  list  for 
remote  terminal 

6 

7-9 

Component 

Identifier 

TPM 

10 

11-13 

LOGON  Code 

LOG 

14 

15-19 

Start 

Ident if ier 

START 

20-21 

22-26 

Date 

Date  in  format  YYDDD 

27 

28-33 

Tiae 

Time  in  format  HHNMSS 

34-46 

47-115 

User 

Maximum  of  70  characters 

Information 

of  LOG  information 

provided  by  the  installa- 
tion validation  subroutine. 
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7.11.6  Terminal  Operator  LOGOFF  Record 

This  record  is  output  for  each  terminal  operator  LOGOFF 
request  as  follows: 


Record 

1 

2-5 


6 

7-9 


10 

11-13 

14 

15-19 

20-21 

22-26 

27 

28-33 

34-57 

58-133 


2£sc£i£tion^CoQtent 


Terminal  Address  3-character  UCB  address 

for  local  terainal;  4- 
character  POLL  list  for 
remote  terminal 

Component 

Identifier  TPH 


LOGOFF  Code 
Stop  Identifier 
Date 
Time 

Comments 


LOG 

STOP 

Date  in  format  YYDDD 
Time  in  format  HHHHSS 
LOGOFF  user  comments 
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7.11.7  Terminal  Operator  REMARKS  Record 

This  record  is  output  Cor  each  terminal  operator  REMARKS 
request  as  follows: 


Record 

Positions 

1 

2-5 


6 

7-9 

10 

11-13 

14-21 

22-26 

27 

28-33 

34-57 

58-133 


field 

Terminal  Address 

Component 

Identifier 

REMARKS  Code 

Date 

Time 

Comments 


Description/Content 


3-character  UCB  address  for 
local  terminal;  4-character 
POLL  list  for  remote  terminal 

TPM 


REM 

Date  in  format  YYDDD 
Time  in  format  HHMMSS 
User  comments 
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A REMARKS  record  is  also  output  for  each  terminal 
operator.  LOGON  request  that  has  not  been  successfully 
validated  by  the  installation  validation  subroutine.  The 
format  of  the  record  is  as  follows: 

Record 
£2 si lions 

Field 

Descr ipt ion /Content 

1 

2-5 

r 

Termina  1 
Address 

3-character  UCB  address  for 
local  terminal  4-character 

POLL  list  for  remote  terminal 

O 

7-9 

10 

11-13 

Component 

Identifier 

REMARKS  Code 

TPM 

REM 

14-21 

22-26 

Date 

Date  in  format  YYDDD 

27 

28-33 

Time 

Time  in  format  HHMMSS 

34 

35-55 

LOGON  Error 

LOGON  VALIDATE  ERROR- 

• 

56 

57-58 

Error  Level 

1 , 2,  or  3 

59-128 

User  Informa- 
tion 

Maximum  of  70  characters 
of  LOGON  information 

provided  by  the  installa- 
tion validation  subroutine. 
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7.11.8  Problem  Program  Initialization  Record 


This  record  is  output  by  the  TP  Supervisor  just  prior  to 
the  Problem  program  execution  as  follows: 


Record 

Editions 

1 

2-5 


6 

7-9 

1C 

11-13 

14 

15-19 

20-21 

22-26 

27 

28-33 

34 

35-42 

43 

44-4a 

49 

50-55 

56-61 

62-64 

65-118 

119-125 


126 

127-133 


field 


Description/Content 


Terminal  Address 

3-cha 

local 

POLL 

Component 

TPS 

I dent  if ier 

Problem  Program 

PP 

Code 

racter  UCB  address  for 
terminal;  4-character 
list  for  remote  terminal 


Start  Identifier 

Date 

Time 

Program  Name 
Input  Record  Count 
Core 


START 

Date  in  format  YYDDD 

Time  in  format  HHdHSS 

Problem  program  name 

Number  of  lines  on  IMQ 

Length  of  largest  available 
block  of  core 


DPRTY  Terminal/program  dispatching 

prior  it  y 

LOCKOUT  The  word  LOCKOUT  if  an  attempt 

was  made  to  load  a second  major 

program  when  LOCKOUT  was  specified 

EXPRFSS  The  word  EXPRESS  if  terminal 

was  given  express  priority  by 
the  operator  for  this  request. 
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7.11.9  Problem  Program  Termination  Record 

This  record  is  output  by  the  TP  Supervisor  just  after 
problem  prograa  termination  as  follows: 


Record 

Posi trons  ligld  Descript ion/Con ten  t 

1 

2-5  Terminal  Address  3-character  UCB  address  for 

local  terminal;  4-character 
* POLL  list  for  remote  terminal 

6 


7-9 

10 

Component 

Identifier 

TPS 

11-13 

14 

Problem  Prograa 

Code 

PP 

15-19 

20-21 

Stop  Identifier 

STOP 

22-26 

27 

Date 

Date  in  format  YYDDD 

28-33 

34 

Time 

Time  in  format  HHHMSS 

35-42 

43 

Program  Name 

Problem  program  name 

44-48 

49 

Output  Record  Count 

Number  of  lines  on  OMQ 

50-54 

Return  Code 

Problem  program  return  code 
if  it  completes;  if  not: 

111 11*prograa  was  never 
started 

ABEND=prograa  ABEND' ed 
ABORT=prograa  aborted  by 
terminal  operator 

55-5o 
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Record 

££sitio£s 

Fie^d 

££S££i£tio£^conteQt 

57-60 

Systea  Completion 
Code 

If  systea  ABENDed  systea 
completion  code  in  the 
format  SXXX 

61 

62-6 1> 

67-133 

User  Completion 
Code 

If  problem  program  ABENDed , 
user  completion  code  in  the 
format  UXXX 
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7.11.10  Problem  Prograa  Batch  Job  Submitted  Record 


This  record  is  output  by  the  TP  Supervisor  when  a JOB 
card  is  encountered  in  the  EDIT  SUBMIT  job  stream  as 
follows: 


Record 

Positions  Field  fiesctiEtioji^Content 


1 

2-5 


6 

7-9 

10 
11-13 
14-21 
22-26 
27 
28-3  3 
34 

35-114 


Terminal  Address  3-character  UCB  address  for 

local  terminal;  4-character 
POL  list  for  remote  terminal 


Component  TPS 

Ident if ier 


Task  Identifier  BJ 


Date 


Date  of  submission 


Time 


Time  of  submission 


Job  Card 


The  full  80-character  JOB 
card  from  the  job  stream. 
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7.11.11  Independent  Graphics  Program  Initialization  Record 

This  record  is  output  by  the  TP  Supervisor  just  prior  to 
Independent  Graphics  program  execution  as  follows: 

Record 

Positions  Field  Description/Content 


1 


2-5 

Terminal  Address 

6 

7-9 

Component 

Identifier 

10 

11-13 

Inde  pendent 
Graphics  Code 

14 

15-19 

20-21 

Start  Identifier 

22-26 

Date 

27 

28-33 

Time 

34 

35-42 

Program  Name 

43 

44-48 

Input  Record  Count 

49-61 

62-64 

DPRTY 

65-126 

127-133 

EXPRESS 

3-character  UCB  address  for 
local  terminal;  4-character 
POLL  list  for  remote  terminal 

TPS 


IGP 


START 

Date  in  format  YYDDD 

Time  in  format  HHMMSS 

Independent  Graphics  program 
name 

Number  of  lines  on  IHQ 

Terminal/program  dispatching 
priorit  y 

The  word  EXPRESS  if  terminal 
was  given  express  priority  by 
the  operator  for  this  request 
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7.11.12  Independent  Graphics  Program  Termination  Record 

This  record  is  output  by  the  TP  Supervisor  just  after 
Independent  Graphics  program  termination  as  follows: 


Record 

EfiSilions 

1 

2-5 


field 

Terminal  Address 


Description/Content 


1-character  UCB  address  for 
local  terminal;  4-character 
POLL  list  for  remote  terminal 


: > 

7-9 

Component 

Ident if ier 

TPS 

10 

11-13 

Independent 

Graphics  Program 
Code 

IGS 

14 

15-19 

Stop  Identifier 

STOP 

1 

20-21 

22-26 

Date 

Date  in  format  YYDDD 

27 

1 

28-33 

Time 

Time  in  format  HHMHSS 

< 

34 

35-42 

Program  Name 

Independent  Graphics 
program  name 

1 

1 

43 

1 

44-48 

Output  Record  Count 

Number  of  lines  on  ONU 

1 

49 

50-54 

Return  Code 

Independent  Graphics  progr 
return  code  if  it  complete 
if  not: 

1 1 1 1 1=program  was  never 

- 

started 

ABEND=program  ABEND* ed 

1 

A BO PT= prog ram  aborted  by 

• 

55-133 

terminal  operator 
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7.11.13  PAGE  Program  Initialization  Record 

This  record  is  output  by  the  TP  Monitor  just  prior  to 
the  terminal  entering  the  conversational  mode  as  follows: 


Record 

£2§itions 

1 

2-5 


6 

7-9 


10 

11-13 

14 

15-19 

20-21 

22-26 

27 

28-33 

34 

35-42 

43-133 


Field  Descript ion/c on ten  t 


Terminal  Address  3-character  HCB  address  for 

local  ♦■erminal;  4-character 
POLL  list  for  remote  terminal 


Component  TPS 

Ident if  ier 

Conversational  CP 

Program  Code 

Start  Identifier  START 


Date 

Time 

program  Name 


Date  in 

Time  in 

Convers 

name 


forma  t 
format 
ational 


YYDDD 

HHHMSS 

Program 
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7.11.14  PAGE  Program  Ter  mi  natior:  Record 

This  record  is  output  by  the  TP  Monitor  just  after  the 
conversation  mode  is  terminated  as  follows: 

Record 

Positions  Field  Description/Content 

1 

2-5  Terminal  Address  3-character  UCB  address  for 

local  terminal;  4-character 
POLL  list  for  remote  terminal 

6 

7-9  Component  TPS 

Ident if ier 

10 

11-13  Conversational  CP 

Program  Code 
14 

15-19  Stop  Identifier  STOP 

20-21 

22-26  Date  Date  in  format  YYDDD 

27 

28-33  Time  Time  in  format  HHMMSS 

34 

35-42  Program  Name  Conversational  program 

name 
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7.11.15  QUIP  Source  Statement  Record 

This  record  is  output  by  the  TP  Supervisor  when  QUIP  reads  a 
user  source  statement  as  follows: 


Record 


positions 

1 

lisl* 

Descript ion/C ontent 

2-5 

Terminal 

Address 

3-character  UCB  address  for 
Local  terminal;  4-character 

POLL  lis*  for  remote  terminal. 

6 

7 -8 

Component 

Ident if ier 

TPS 

10 

11-13 

Record  Identifier 

QSS  (QUIP  Source  Statement) 

14-21 

22-26 

Date 

Date  in  format  YYDCD 

27 

28-3  3 

Time 

Time  in  format  HHMMSS 

34 

35-41 

Run  Identifier 

This  is  a 7-digit  numeric  field 

assigned  to  each  QUIP  execution. 

It  consists  of  the  two  low  order 
digits  of  the  Julian  day  and  the 
starting  time  of  the  QUIP  execution 
in  seconds. 

This  same  run  identifier  is 
assigned  to  QUIP  Statistics 
Messages  No.  1 and  No.  2 of  the 
same  execution. 


1 
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Record 

eositioQS 

42 

43-122 


123-133 


Field/Header  Description/Content 

Source  Statement  This  is  a display  of  the  user's 

source  statement  as  entered  at 
the  terminal  or  from  a stored 
query. 
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7.11.1b 

This 

execution 

Record 

Positions 

1 

2-5 


6 

7-9 


10 
11-1  J 

14-21 

22-2o 

27 
28-  3 3 

34 

35-41 


QUIP  Statistics  Message  No.  1 Pecord 

record  is  output  hy  the  TP  Supervisor  for  each  QUIP 
as  follows: 

F ifld  Description /Content 


Terminal  3-character  UCB  address  for 

Address  local  terminal;  4-character 

POLL  list,  for  remote  terminal. 


Component 

TPS 

Ident if ier 

Record  Identifier 

QSl  ( Qtl 

Date 

Date  in 

P Statistics  Message  No.  1) 
format  YYDDD 


Time 


Time  in  format  HHMMSS 


Run  Identifier  This  is  a 7-digit  numeric  field 

assigned  to  each  QUIP  execution. 

It  consists  of  the  two  low  order 
digits  of  the  Julian  day  and  the 
starting  time  of  the  QUIP  execution 
in  seconds. 

This  same  run  identifier 
is  assigned  t.o  the  QUIP  Source 
Statement  Pecords  and  to  QUIP 
Statistics  Message  No.  2 Pecords 
of  the  same  execution. 
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Record 

Easiiiansi  lisl^Ilsadsr 

42 

43-8b  File  Name 

87-118  File  Class 


119 

120-123  Query  Number 


124 

133 


44-character  field  for  the  file  name 

32-charac*er  field  for  the  file 
classification  unless  suppressed  by 
the  operand  'N'  in  the  query 


4-character  field  for  the  query 
number  (space  is  provided  for  this 
field  but  a query  number  is  not 
applicable  for  online  QUIP  executions) 

Query  Number  and  FITID  field 
separator  and  locator  (always  printed) 
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7.11.17  QUIP  Statistics  Message  No.  2 Header  and  Data  Records 

The  header  and  data  records  are  output  by  the  TP 

Supervisor  as  a consecutive  pair  for  each  quip  guery.  The 

header  record  is  put  out  only  as  a visual  aid  to 

interpreting  the  data  record  when  the  output  is  a printed 
copy.  In  the  following  record  format,  positions  1-34 
describe  both  records;  in  positions  35-133,  the  Record 

Positions  column  and  the  rescript ion/Content  column  pertain 
to  the  data  record,  and  the  Rield/Header  column  will  contain 
the  actual  header  associated  with  that  field. 


Record 

ESSitiafis 

liSld^He^der 

Description/Content 

1 

2-5 

L. 

Terminal  Address 

3-character  UCB  address  for 
local  terminal;  4-character 

POLL  list  for  remote  terminal. 

O 

7-9 

Component 

Identifier 

TPS 

10 

1 1-13 

Record  Identifier 

QS2  (QUIP  Statistics  Message  No.  2) 

14-21 

22-26 

Date 

Date  in  format  YYDDD 

28-33 

Time 

Tine  in  fornat  HHMMSS 

34 

35-41 

RIJNT  D 

Run  Identifier  - This  is  a 7-digit 
numeric  field  assigned  to  each  QUIP 
execution.  It  consists  of  the  two 
low  order  digits  of  the  Julian  day 
startihg  time  of  the  QUIP  execution 
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Record 

E2§ill2BS  Field/Header 


42 

43-44  PC 


45 

46-50  LINES 


51-52 

53-55  WAITS 


56-57 

58-66  QUIP-ET 


Description/Content 

in  seconds.  This  same  run  identifier 
is  assigned  to  the  QUIP  Source 
Statement  Pecords  and  the  QUIP 
Statistics  Message  No.  1 Record  of 
the  same  execution. 


Return  Code  - This  is  a 2-character 
field  derived  from  a bit  ORed  composite 
of  QUIP  error  message  severity  levels. 
For  example,  if  RC-09,  it  would  indicate 
that  there  was  at  least  one  level-8 
and  one  level-1  error  message  for  the 
QUIP  execution. 


This  entry  specifies  the  number 
of  lines  written  by  QUIP  to  the 
OMQ  (Output  Message  Queue) . If 
OMQ=NO  was  specified,  the  value  is 
the  number  of  lines  written  to  the 
VIEW  data  set  member,  or  zero  if  a 
VIEW  data  set  member  was  not 
specified. 


The  number  of  1.0  second  wait  periods 
executed  by  QUIP  when  attempting  to 
get  main  storage  that  was  unavailable. 
Each  wait  period  is  preceded  by  an 
unsuccessful  GETNAIN. 


Elapsed  time  of  the  QUIP  execution, 
in  seconds  and  hundredths  of  seconds. 


67 

68-76  SETUP-ET  Elapsed  time  t.o  the  start  of  the  file 

search  in  seconds  and  hundredths  of 
seconds. 
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Record 

Positions 

Descript-  ion/Content 

77 

7 6-  6b 

O'JTST-ET 

Out-put  Start  Elapsed  Time.  The 
elapsed  time  in  seconds  and  hundredths 
of  seconds  from  QUIP  start  time  to  the 
availability  of  the  first  line  of 
output. 

67 

3b-95 

CPU-TINE 

Total  CPU  time  included  in  the  total 
elapsed  time. 

96 

97-102 

FPL 

The  number  of  records  passing  the 
limits  or  retrieved. 

103 

104-109 

R0 

The  number  of  qualifying  records. 

110 

111 

L 

Limit  statement  used  indicator. 

Y=yes,  N=no. 

1h 

112-118 

CANDTS 

The  number  of  candidates  if  the 
retrieval  were  indexed;  if  not, 
the  field  will  contain  'NA'. 

119 

120-125 

R-EXCP 

Hetrieval  EXCF  count  (I/O  operations) 

126 

127-1 32 

S-EXCP 

Sort  EXC?  count  (I/O  operations) 
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7.11.18  QUIP  Statistics  Message  No.  3 Record 

This  record  is  output  by  the  TP  Supervisor  for  each  QUIP 
execution  with  a query  containing  a SORT  statement.  The 
following  describes  the  format  and  content  of  the  message. 

Record 

Positions  Field  Descr iption/Content 

1 

2-5  Terminal  Address  3-character  UCB  address 

for  local  terminal; 
4-character  POLL  list  for 
remote  terminal. 

6 


7-9 

Component 

Ident if ier 

TPS 

10 

1 1-13 

Record  Identifier 

QS3  (QUIP  Statistics 
Message  No.  3) 

14-21 

22-26 

Date 

Date  in  format  YYDDD 

27 

28-33 

Time 

Time  in  format  HHMMSS 

34 

35-41 

Run  Identifier 

This  is  a 7-digit  numeric 
field  assigned  to  each 

QUIP  query.  It  consists 
of  the  two  low  order 
digits  of  the  Julian 
day  and  the  starting 
time  in  seconds. 


42 

43-74 

Process  Block 

This  field  contains  the 

Disk  Space 

following  subfields: 

56-59 

Statistics 

The  number  of  PB  tracks 

specified  on  first 
allocation  attempt. 
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Editions 

61-63 

65-b8 

70-73 


76-77 

80-83 

85-87 

89-92 

94-97 


Field  Rescript ion/Content 

The  number  of  PB  space 
allocation  attempts. 

The  number  of  disk 
tracks  allocated  for 
PB  space. 

The  number  of  disk 
tracks  actually  used. 

This  number  may  be 
larger  than  the  number 
allocated  because  of 
secondary  extents. 

Sort  Key  Disk  This  field  contains 

Space  statistics  the  following  sub- 

fields. 

The  number  of  sort  key 
tracks  specified  on 
the  first  allocation 
attempt . 

The  number  of  sort  key 
space  allocation  attempts. 

The  number  of  tracks 
allocated  for  sort  key 
space . 

The  number  of  tracks 
actually  used. 
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7.11.19  QUIP  Statistics  Message  No. 4 Header  and  Data 
Hecords 

The  header  and  data  records  are  output  by  the  TP 
Supervisor  as  a consecutive  pair  for  each  query  which 
processes  a subfile.  The  header  record  is  put.  out  only  as 
a visual  aid  to  interpreting  the  data  record  when  the  output 
is  a printed  copy.  In  the  following  record  format, 
positions  1-34  describe  both  records.  In  positions  35-133, 
the  Record  Positions  column  and  the  Description/Content 
column  pertain  to  the  data  record,  and  the  Pield/Header 
column  show  the  actual  header  associated  with  that  field. 

Record 

Positions  Field/Header  Description^Content 

1 


2-5 

£ 

Terminal  Address 

3- character  HCB  address 
for  local  terminal; 

4- character  POLL  list 
for  remote  terminal. 

o 

7-9 

Component 

Identifier 

TPS 

10 

11-13 

Record 

QS4  (QUIP  Subfile 

Identifier 

Statistics) 

14-21 

22-26 

Date 

YYDDD 

27 

28-33 

Time 

HHMMSS 
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Record 

positions  Field/Header  Description/Content 

34 

35-41  RUNID  Ran  Identifier  - This  is  a 

7-digit  numeric  field  assigned 
to  each  QUIP  execution.  It 
consists  of  the  two  low  order 
digits  of  the  Julian  day  start- 
ing time  of  the  QUIP  execution 
in  seconds.  This  same  run 
identifier  is  assigned  to  the 
QUIP  Source  Statement  Records 
and  the  QUIP  Statistics  Message 
No.  1 and  2 Records  of  the 
same  execution. 


42 

43-49 

IN OUT 

Subfile  input  member  name. 

50 

51-55 

COUNT 

Number  of  entries  in  input 

5b 

57-59 

SEQ 

subfile. 

Input  sequence  number.  Each 

60-61 

62-64 

LEVEL 

subfile  created  in  a unique 
PDS  is  assigned  a consecutive 
number. 

Input  level  number.  Each 

65-69 

70-76 

OUTPUT 

subfile  in  one  chain  is 
assigned  a consecutive 
number. 

Subfile  output  member  name. 

77 

78-82 

COUNT 

Number  of  entries  in  output 

subfile. 


118 


INSTALLATION 


Record 

£2§i£.i2ns 

83 

84>8b 

87-88 

89-91 


fiellZHeader 

SEQ 

LEVEL 


92-133 


Description/Content 


Output  sequence  number. 


Output  level  number, 
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7.11.20  SODA  Statistics  Message  No.  0 Header  and  Data 

Records 

The  header  and  data  records  are  output  by  the  TP 
Supervisor  for  each  successful  signon  to  SODA.  The  header 
record  is  put  out  as  a visual  aid  for  interpreting  the 
subsequent  data  record.  The  record  is  output  as  follows: 

Record 

position  Field/Header  Qescrj.pt  ion/C  on  ten  t 

1 

2-5  Teminal  Address  3-character  UCB  address 

for  local  terminal ; 4- 
c haracter  POLL  list  for 
remote  terainal. 

6 


7-9 

10 

Component 

Ident if ier 

TPS 

11-13 

Record 

FM0  (SODA  Statistics 

14-21 

Ident if ier 

Message  No.  0) 

22-26 

27 

Date 

Date  in  format  YYNMDD 

28-33 

34 

Tine 

Time  in  format  HHNHSS 

35-41 

42-43 

RUNID 

Run  Identifier  (see  Section 
7.11.19) 

44-87 

88-89 

FILE  NAME 

File  Naae 

90-101 

102-106 

HOLD  FILE  NAME 

Name  of  hold  file 

107-114 

REPORT  NAME 

Report  name 
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7.11.21  SODA  Statistics  Message  No.  1 Header  and 
Data  Records 

The  header  and  data  records  are  output  by  the  TP 
Supervisor  for  each  Soda  transaction.  The  header  record  is 
put  out  as  a visual  aid  for  interpreting  the  subsequent  data 
record.  The  record  is  output  as  follows: 

Record 


Position 

Fieid 

Besctiption^Content 

1 

Terminal 

3-character  OCB  address 

2-5 

(L 

Address 

for  local  terminal;  4- 
character  POLL-list  for 
renote  terninal. 

O 

7-9 

Component 

Identifier 

TPS 

10 

11-13 

Record 

PHI  (SODA  Statistics  Message 

Identifier 

NO.  1) 

14-21 

22-2t» 

Date 

Date  in  format  YYHNDD 

27 

28-33 

Tine 

Tine  in  format  HHHHSS 

34 

35-41 

RUNID 

Run  Identifier  (see 

Section  7.11.19) 

42-46 

EPP-CODE 

Error  Code.  This  value  is 

47-48 

00  if  the  logic  statement 
executed  without  error.  If 

the  input  was  retained  for 
correction  this  value  will 
be  04. 
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Record 

E2siti23 

49-^7 

58-62 


63-6  7 
68-72 


73-77 

78-81 


field 

BLDPB-ET 


LS-ET 


UP-ET 


Description /Content 

Build  Process  Block  Elapsed 
Time.  This  is  the  elapsed 
time  in  hundredths  of  seconds 
from  the  start  of  SODA  to  the 
availability  of  the  process 
block. 

Logic  Statement  Elapsed  Time. 
This  is  the  elapsed  time  in 
hundredths  of  seconds  for  the 
execution  of  the  user's  logic 
statement . 

Update  Elapsed  Time.  This  is 
the  elapsed  time  in  hundredths 
of  seconds  for  post  logic 
statement  processing. 
Currently,  this  value  will 
appear  as  000  since  all  update 
records  are  placed  on  the  hold 
file. 


| 
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7.11.22  SODA  Statistics  Message  No.  2 Record 

This  record  is  output  by  the  TP  Supervisor  for  each  SODA 
UPDATE  or  CANCEL  command  as  follows: 

Record 


position 

field 

Description/Content 

1 

2-5 

Terminal 

3-character  UCB  address  for 

Address 

local  terminal;  4-character 

A, 

POLL-list  for  remote  terminal. 

0 

7-9 

Component 

Ident if ier 

TPS 

10 

11-13 

Record 

FM2  (SODA  Statistics 

Ident if ier 

Record  No.  2) 

14-21 

22-26 

Date 

Date  in  format  YYMMDD 

27 

28-33 

Time 

Time  in  format  HHMKSS 

34 

35-41 

RUNID 

Run  Identifier  (see 

Section  7.11.19) 

42-45 

46-54 

U/C  IND 

Field  Label-Update/Cancel 
Indicator 

55 

Update/Cancel 

This  field  will  contain 

Indicator 

a '0*  or  'C'  indicating 

whether  the  user  has 
entered  an  update  or 
CANCEL  command 
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Record 

Positron  field  Pe?cr  ipt  jon/Content 

56-60 

61-69  EXEC-ET  Field  Label-Execution 

Elapsed  Time 

73-7B  Execution 

Elapsed  Time  This  is  the  elapsed 

time  in  hundredths  of 
seconds  to  perform  the 
UPDATE  or  CANCEL. 
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7.11.23  FORMATTER  Statistics  Message  No.  1 Header  and  Data 
Records 

The  header  and  data  records  are  output  by  the  TP 
Supervisor  as  a consecutive  pair  for  each  fornat  processed 
by  FORMATTER.  In  the  following  record  fornat,  positions  1- 
34  describe  both  records;  in  positions  35-110,  the  Record 
Positions  column  and  the  Description/Content  colunn  pertain 
to  the  data  record,  and  the  Field/Header  will  contain  the 
actual  header  associated  with  that  field. 


Record 

E25iU2S§  Field/Header  Description/Content 

1 

2-5  Terminal  Address  3-character  UCB  address  for 

local  terninal;  4-character 
POLL  list  for  remote  terminal. 

6 

7-9  Component  TPS 

Ident if ier 

10 

11-13  Record  0S1  - header  record 

Identifier  0S2  - data  record 

14-21 

22-26  Date  Date  in  format  YYDDD 

27 

28-33  Time  Time  in  format  HHNHSS 

34 

35-74  User  Library  User  Library  Tata  set  name. 

DSNAME  The  name  of  the  data  set 

that  contains  the  format 
being  accessed. 

75-79 

80-87  FORMAT  Format.  The  name  of  the 

fornat  being  accessed. 

88 

89-94  ACCESS  Access  Elapsed  Tine.  This 

is  the  elapsed  time  in 
hundredths  of  seconds  needed 
to  load  the  fornat. 
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Record 

Visions 

Field/Header 

Description/Content 

95 

96-101 

EXEC 

Execution  Elapsed  Time.  This 
is  the  elapsed  time  in  hundredths 
of  seconds  for  the  processing  of 
the  formats. 

10^-103 

104-105 

CHAIN 

Number  of  Chained  Formats. 

This  field  contains  the  number 
of  formats  accessed  prior  to 
executing  the  invoiced  component. 

106-108 

109-110 

EPP 

Number  of  Error  Retries.  This 
field  contains  the  number  of 

retries  necessary  to  complete 
all  the  data  required  fields. 

1 


12  6 


I 

i 


A 


I 

• l - 
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7.11.24  FORMATTER  Statistics  Message  No.  2 Header  and  Data 
Records 

The  header  and  data  records  are  output  by  the  TP 
Supervisor  as  a consecutive  pair  for  each  format  UPDATE 
processed  ny  FORMATTER.  In  the  following  record  format, 
positions  1-34  describe  both  records;  in  positions  35-132, 
the  Record  Positions  column  and  the  Description/Contert 
column  pertain  to  the  data  record,  and  the  Field/Header  will 
contain  the  actual  header  associated  with  that  field. 


Record 


field^Headet 

i 

2-5 

Terminal 

Address 

6 

7-9 

Component 

Identifier 

10 

1 1-13 

Record 

Ident if ier 

21 

22-26 

Date 

27 

28-33 

Time 

34 

35-68 

Source  Input 
Library 

69 

70-77 

Input  Member 

78 

79-112 

Format  Output 
Library 

Description/Content 


3-character  UCB  address  for 
local  terminal;  4-character 
POLL  list  for  remote  terminal 

TPS 


05 3 - header  record 

054  - data  record 

Date  in  format  YYDDD 

Time  in  format  HHMMSS 

Source  Input  Library  Data 
set  name.  This  field 
contains  the  name  of  the 
source  input  library. 

Input  Member  Name.  This 
field  contains  the  name  of 
the  input  source  member. 

Format  Output  Library  Data 
Set  name.  This  field 
contains  the  name  of  the 
output  library,  where  the 
format  was  stored. 
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Record 
££  sitioiis 

113 

114-121 


122 

123-126 


127 

128-132 


Field/Header 


Descr iptiop/Conten t 


Output  Member 


Size 


EXEC 


Output  Member  Name.  This 
field . contains  the  name  of 
the  output  member. 

Size  of  Format.  This  field 
contains  the  size  in  bytes 
of  the  format. 

Execution  Elapsed  Time. 

This  is  the  elapsed  time 
in  hundredths  of  seconds 
needed  for  the  definition 
and  storage  of  the  format. 
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7.11.25  FORMATTER  Statistics  Message  No.  3 Data 

Records 

If,  when  signing  on  to  FORMATTER,  the  debug  snapshot  is 
invoiced  (0256  -»0) , each  line  of  the  Input  Message  Queue 
(IMQ)  created  by  each  format  will  be  logged  in  the  following 
record  format: 

£2siti2fls  Field/Header  Desc£i£t ion^Conteat 

1 


2-5 

Teminal  Address 

3-character  DCB  address 

for  local  terminal;  4-character 

POLL  list  for  renote 

terminal. 

0 

7-9 

Component 

Ident if ier 

TPS 

10 

11-13 

Record 

Ident  if  ied 

OSS  - data  record 

14-21 

22-2b 

27 

Date 

Date  in  format  YYDDD 

28-33 

34 

Tine 

Tine  in  format  HHMMSS 

35-114 

IRQ 

One  line  of  IMQ  created 

by  the  format  identified 
in  the  preceding  FORMATTER 
Statistical  Record  #1. 

This  record  format  will  be 
repeated  until  the  entire 
IRQ  has  been  written. 
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7.12  Terminal/Program  Priority 

The  concept  of  ter tn in al /program  affords  the  user  maximum 
flexibility  in  establishing  priorities  within  the  TP 
environment.  Four  priority  environments  are  available: 


The 

"first 

i 

n,  first 

out” 

en 

pro 

blem  p 

ro 

gram  requests  a 

re 

in. 

first 
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ut  basis. 

i.  e. 

* 1 
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ered , 
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t assumes 

high 

er 

sub 

sequent 

req  uests. 

Th 
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by  assign: 
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generating  the  TP  Monitor  a 
respectively.  Allowing  all  PP^Y 
assume  their  default  values 
env ironmen t . 


ironment  in  w 
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priorities 
nd  TP  Supervi 
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will  result  in 
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is 
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is 
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this 


b.  The  terminal  priority  environment  in  which  requests 

are  processed  in  order  of  relative  terminal 

priority.  This  environment  is  established  by 
assigning  relative  terminal  priorities  and  equal 
problem  program  priorities  when  generating  the  TP 
Monitor  and  TP  Supervisor,  respectively. 

c.  The  problem  program  priority  environment  in  which 

requests  are  processed  in  order  of  relative 

priority  of  the  problem  program  requested. 

d.  The  terminal  and  program  priority  environment  ir. 
which  requests  are  processed  in  order  of  relative 
ter minal/program  priority  combinations. 

The  four  priority  environments  are  achieved  within  one 
priority  scheme,  that  of  terminal/program  priority 
combinations.  The  TP  Supervisor  uses  the  terminal/program 
priority  combination  to  compute  the  dispatching  priority  of 
the  request.  Requests  are  queued  and  dispatched  in 
dispatcning  priority  order.  Dispatching  priorities  are 
derived  as  follows: 
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Task  dispatching  priority  = 

TPS  UP  dispatching  priority  - 

((highest  ter minal/progr am  priority  *1)  - 

(terminal/program  priority  combination  of  request)) 


7.12.1  TP  Terminal  Priority  Modification  by  Operator 

Terminal  priorities  are  established  at  TP  Monitor 
generation  time  and  are  the  priorities  in  effect  when  the  TP 
Monitor  is  initialized.  Once  the  ""P  Monitor  has  been 
initialized,  terminal  priorities  may  be  changed  by  the 
computer  operator.  Terminal  priorities  so  assigned  remain 
in  effect  until  subsequently  changed  again  or  the  TP  Monitor 
is  reinitialized. 

To  change  terminal  priorities,  the  operator  must  reply 
to  the  TP  standing  request  that  is  always  issued  by  the  TP 
Monitor. 

The  operator  responds  to  this  request  with  the  keyword 
PRTY  followed  by  the  terminal  name,  terminal  names  enclosed 
within  parentheses,  or  ALL  and  the  new  priority  value.  ALL 
will  cause  all  terminal  priorities  to  be  changed  to  the  new 
priority  value.  Terminal  names  or  ALL  must  be  separated 
from  the  priority  value  by  one  or  more  blanks  or  commas. 
All  characters  within  the  reply  must  be  uppercase.  The 
priority  value  must  be  numeric  and  has  a range  of  1 to  15  or 
the  word  'EXPRESS*.  EXPRESS  may  not  be  specified  with  ALL. 
Express  priority  will  give  the  terminal(s)  the  highest 
priority  for  one  TP  problem  program  request.  A successful 
priority  change  will  be  indicated  by  the  following  response 
to  the  operator: 

TERMINAL(S)  PRIORITY  CHANGE  COMPLETED 
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At  the  terminal  receiving  a newly  assigned  priority,  the 
following  message  will  appear: 

*****  TERMINAL  PRIORITY  IS  XX  EXPRESS 

In  the  above  example,  XX  is  the  priority  of  the 
terminal.  The  word  EXPRESS  will  appear  as  part  of  the 
message  only  when  the  operator  assigns  express  priority  to 
the  terminal. 

If  an  invalid  terminal  name  is  specified,  the  following 
error  message  will  be  returned: 

TERMINAL  (terminal  name)  NOT  FOUND 

The  following  error  message  will  be  returned  if  the 

reply  format  is  incorrect: 

INVALID  PPTY  REPLY  wORM AT 

If  the  priority  value  is  not  specified,  the  following 
error  message  will  be  returned: 

PRTY  VALUE  NOT  SPECIFIED 

The  following  error  message  will  be  returned  if  an 

invalid  priority  value  is  specified: 

PRTY  VALUE  MUST  BE  NUMERIC  (VALUES  1 THRU  15) 


7.13  Time-Slicing 

The  time-slicing  facility  allows  the  user  to  establish 
a group  of  tasks  or  partitions  (called  the  time-slice  group) 
that  are  to  share  the  use  of  the  CPU;  each  for  the  same, 
fixed  interval  of  time.  Implementation  of  this  facility 
differs  slightly  in  HFT,  MFT  with  subtasking,  and  HVT 
systems.  The  resultant  capability  operates  the  same  in  all 
systems.  The  difference  occurs  in  the  generation  of  OS  for 
time-slicing. 


In  an  HFT  environment  without  subtasking,  a partition 
must  be  established  for  each  priority  group  desired.  This 
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partition  must  also  contain  a resident  TP  Supervisor. 
Execution  of  tasks  in  these  partitions  is  based  upon  the 
inclusion  or  exclusion  of  specific  programs  and  terminals  at 
TP  generation  time.  Priority  in  this  case  may  be  recognized 
only  by  partitions  and  overrides  the  group  concept  defined 
above. 

To  facilitate  the  interface  with  OS  Time-Slicing,  the 
task  dispatching  priorities  derived  by  the  method  set  forth 
in  section  7.8,  Terminal/Program  Priority,  will  be  ordered 
into  several  groups.  Tasks  within  each  group  will  be 
attached  at  the  sane  OS  job  priority.  Group  membership  for 
a particular  terminal/program  priority  is  determined  in  the 
following  manner: 

a.  If  only  one  group  is  specified  by  the  user,  all 
tasks  in  the  TP  environment  are  attached  at  a 
dispatching  priority  16  less  than  that  of  TPSUP. 
This  is  equivalent  to  decrementing  the  job  priority 
of  the  task  by  one.  That  is,  if  TPSUP  is  a 
priority  13  job,  all  tasks  will  be  considered  the 
same  as  priority  12  jobs. 

b.  If  two  groups  are  requested,  the  highest 

terminal/program  priority  in  the  system  is  halved 
and  the  result  is  truncated.  All  terminal/program 
priority  combinations  greater  than  this  limit  are 
members  of  Group  1 and  are  attached  with  a 
dispatching  priority  16  less  than  that  of  TPSUP. 
All  other  combinations  are  placed  in  the  second 
group  and  attached  with  a dispatching  priority  32 
less  than  TPSUP  (i.e.,  two  OS  job  priorities  less). 
Either,  both,  or  neither  of  these  groups  may  be 
time-sliced  at  the  user's  option. 

c.  If  three  groups  are  requested,  the  limit  derived  in 
Step  2 is  halved  again,  the  result  becoming  the 
lower  bound  for  Group  2.  All  combinations  equal  to 
or  less  than  '■his  new  limit  are  placed  in  Group  3 
and  attached  with  a dispatching  priority  48  less 
than  that  of  TPSUP  (3  OS  job  priorities  less) . Any 
combination  of  groups  may  be  tine-sliced  or  not 
time-sliced  at  the  user's  direction. 
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A slight  modification  to  the  above  method  is  necessary 
in  an  HFT  environment  (with  or  without  subtasking).  The 
qroups  established  will  he  attached  at  11,  22,  or  33 
dispatching  priorities  less  than  TPSUP.  This  is  equivalent 
to  a difference  of  1,  2,  or  3 partition  priorities.  The 
remainder  of  the  above  discussion  is  pertinent  in  all  cases. 


7.14  Development  of  an  Installation  Written  Validation 

Subroutine 

The  NIPS  Terminal  Processing  Component  and  TP 
application  programs  contain  the  linkage  needed  to  interface 
with  an  installation  validation  subroutine,  written  by  the 
user,  designed  to  control  the  rightful  access  to  the  TP 
terminal  devices  and  data  files.  The  user  written 
validation  subroutine  is  optional  and  may  be  as  simple  or 
complex  as  the  installation  requires.  If  the  optional 
validation  subroutine  is  specified  by  the  user,  an  exit  to 
such  a subroutine  will  be  made  at  the  following  points  in 
time: 

1.  Terminal  LOGON 

2.  File  Open  (for  QUIP,  SODA,  ODE,  VIEW) 

When  writing  the  installation  validation  subroutine 
certain  conventions  must  be  followed.  The  following 
subsections  describe  such  conventions. 


7.14.1  Specification  of  an  Installation  Written  Validation 
Subroutine 

The  presence  of  an  installation  validation  subroutine  is 
indicated  by  specifying  the  appropriate  keyword  option  on 
the  QTPHOPT  macro  at  TP  Monitor  generation  time.  To  specify 
an  installation  validation  subroutine  using  the  QTPHOPT 
macro,  the  following  format  is  used: 

QTPHOPT  V ALID=XXXIXXXX, . . . 


where  xxxxxxxx  is  the  1-8  character  entry  point  name  of  the 
validation  subroutine. 
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The  installation  validation  subroutine  will  be  included 
at  linkedit  time  as  a part  of  the  generated  TP  Monitor 
aodule.  For  a complete  description  of  the  QTPMOPT  macro, 
see  section  7.4  of  this  manual. 


7.14.2  The  Validation  Subroutine  Program  Interface 
Specifications 

The  user  written  installation  validation  subroutine 
should  follow  the  standard  0S/36C  linkage  and  NIPS  Subloader 
conventions  as  specified  in  section  3 of  Volume  I, 
Introduction  to  File  Concepts.  Three  parameters  are  passed 
to  the  user  routine.  Parameter  one  is  the  entry  point  to 
the  NIPS  subroutine  loader.  Parameter  two  points  to  the 
parameter  area  which  is  described  in  detail  in  the  following 
sections.  Parameter  three  is  a cell  for  return  code 
storage.  The  subroutine  loader  entry  point  is  provided  to 
the  user  validation  subroutine  so  that  requests  to  load  or 
link  to  other  routines  and/or  tables  are  possible.  The  high 
order  byte  of  parameter  two  contains  either  L or  F 
indicating  whether  the  subroutine  is  being  branched  to  at 
terminal  LOGON  or  File  Open  time,  and  thus  determines 
whether  the  parameter  area  has  the  format  of  LOGON  or  File 
Open  data.  The  one  character  cell  designated  by  parameter 
three,  or  register  15,  can  contain  a return  code  of  0,  1,  2, 
or  3.  The  installation  written  validation  subroutine  should 
be  compiled  and  linkedited  to  FFS.JOBLIB,  so  it  is  available 
at  TP  Monitor  generation  time.  The  installation  validation 
subroutine  should  not  be  loaded  to  FFS.JOBLIB  by  the  NIPS 
SUBLOADER  procedure. 


7.14.3  Terminal  LOGON:  Parameter  Area 

At  terminal  LOGON  the  parameter  area  pointed  to  by 
parameter  two  will  contain  the  LOGON  data,  exclusive  of  the 
keyword  LOGON,  a cell  for  the  encoded  data  value  resulting 
from  a successful  LOGON,  the  terminal  device  type,  the 
terminal's  UCB  address,  the  time  of  LOGON  attempt  and  areas 
for  optional  messages  to  the  terminal  user  and  console 
operator.  By  using  the  macro  QTPLGDEP  and  coding  a USING 
TPLGDEP  instruction  in  the  validation  subroutine,  the 
following  fields  can  be  referenced: 
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TPLGDEP 

DSECT 

LGDATA 

DS 

CL70 

TERMINAL  INPUT  EXCLUDING  KEYW'OPD  LOGON  START 

* 

DATA  HPI^^EN  ON  TPLOG  DATASET  AS  REM  OR  LOG  START 

LGCODE 

DS 

CL4 

ENCODED  VALUE  - PROPER  LOGON  OCCURRED 

LGDEVTYP 

DS 

CL1 

DEVICE  TYPE 

X'  01  • 

= LOCAL  2260 

X'  02* 

= LOCAL  2250 

X*  10' 

= REMOTE  2260 

X'  20* 

= CTAL=UP  1050 

X'  40* 

= 2741 

X'  80' 

= 3270 

LGDEVNUM 

DS 

CL3 

tJCB  ADDRESS 

LGTIME 

DS 

CL4 

LOGON  TIME  HHMM 

LGMGTERM 

DS 

CL70 

OPTIONAL  MSG  TO 

TERMINAL  OPERATOR 

LGMGCON- 

DS 

CL70 

OPTIONAL  MSG  TO 

CONSOLE  OPERATOR 

7. 14.4 

Ter  m inal 

LOGON: 

Consequence  of 

Return  Codes 

Upon  return  from  the  user  written  validation  subroutine 
register  15  or  the  one  character  cell  designated  by 
parameter  three,  can  contain  a hex  value  of  0,  i,  2,  or  3. 


A return  code  of  0 indicates  that  the  terminal  user  has 
supplied  valid  accounting  data  and  the  terminal  is  to  logged 
on.  The  data  in  the  LGDATA  area  of  the  TPLGDEP  DSECT  is 
written  out  on  the  TPLOG  data  set  in  a LOGON  START  record, 
positions  47-115.  The  user  subroutine  may  overlay  the 
actual  LOGON  data  with  an  unclassified  version  of  the 
information.  The  encoded  value  placed  in  the  LGCODE  area  is 
stored  in  the  Terminal's  Unit  Status  Table  so  that  it  will 
be  available  at  file  open. 

A return  code  of  1 indicates  that  the  terminal  user  has 
supplied  incorrect  accounting  data  and  that  the  terminal  is 
not  to  be  logged  on.  The  error,  however,  is  considered  to 
be  minor  and  the  user  is  allowed  to  attempt  to  LOGON  again. 
The  data  in  the  LGDATA  area  is  written  out  on  the  TPLOG  data 
set  in  a REMARKS  record,  positions  58-127.  The  standard 
message  LOGON  INFORMATION  MISSING  OR  INCORRECTLY  SPECIFIED 
is  written  out  to  the  terminal  user  and  followed  with  the 
optional  message,  is  specified  in  the  LG"GTFPH  area. 
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A return  code  of  2 indicates  that  the  terminal  user  has 
supplied  incorrect  accounting  data  and  that  the  terminal  is 
not  to  be  logged  on.  The  error  is  considered  to  be  serious, 
but  the  user  is  allowed  to  LOGon  again.  A count  of  serious 
errors  incurred  by  each  terminal  is  maintained.  The  third 
consecutive  occurrence  of  a return  code  of  2 will  cause  any 
further  input  from  that  terminal  to  be  disregarded  until 
(the  system  manager  instructs)  the  computer  console  operator 
to  enable  the  terminal.  The  data  in  the  LGDATA  area  is 
written  out  on  the  TPLOG  data  set  in  a REMARKS  record, 
positions  58-127.  The  standard  message  LOGON  INFORMATION 
MISSING  OR  INCORRECTLY  SPECIFIED  is  written  out  to  the 
terminal  user  and  followed  with  the  optional  message,  if 
specified  in  the  LGMGTERM  area. 

A return  code  of  3 indicates  that  the  terminal  user  has 
supplied  incorrect  accounting  data  and  that  the  error  is 
considered  to  be  gross  in  nature.  The  terminal  is 
immediately  placed  in  a disabled  status.  The  terminal  user 
is  sent  the  standard  message,  TERMINAL  DISABLED  UNTIL 
FURTHER  NOTICE,  and  an  optional  message  if  specified  in  the 
LGMGTERM  area.  The  computer  console  operator  is  informed 
that  UNAUTHORIZED  USER  ATTEMPTING  TO  USE  TERMINAL  xxxxxxxx. 
If  an  optional  message  is  given  the  LGMGCON  area  it  is 
written  to  the  console  operator  after  the  standard  message. 
The  data  in  the  LGDATA  area  is  written  out  on  the  TPLOG  data 
set  in  a REMARKS  record  positions  58-127.  Any  further 
attempt  to  enter  data  by  the  terminal  operator  will  result 
in  the  issuing  of  the  following  message:  NO  INPUT  ALLOWED  - 
TERMINAL  IS  IN  DISABLED  STATUS.  The  computer  console 
operator  can  enable  the  terminal  again  by  replying  to  the 
NIPS  TP  outstanding  request: 

R nn,  * ENABLE  terminal  name' 


7.14.5  File  Open:  Parameter  Area 

At  File  Open  the  parameter  area  will  contain  the  file 
name,  the  member  name  (optional),  the  file  classification, 
the  encoded  value  resulting  from  successful  LOGON,  a cell 
for  the  file  access  code,  and  areas  for  optional  mesages  to 
the  terminal  user  and  console  operator.  By  using  the  macro 
QTPFLDEF  and  coding  a USING  TPFLDEF  instruction  in  the 
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validation  subroutine 

the  following  fields  can  be 

referenced: 

TPFLDEP 

DSECT 

FLNAME 

DS 

CL44 

DATA  SET  NAME 

FLCLASS 

DS 

CL32 

FILE  CLASSIFICATION 

FLLGCODE 

DS 

CL4 

ENCODED  VALUE  OF  SUCCESSFUL  LOGON 

PLACES 

DS 

CL4 

FILE  ACCESS  CODE 

* 

CL1 

R/B/W  READ, WRITE,  OR  BOTH 

* 

CL1 

A/H  ALL/MEMBER 

* 

CL2 

RESERVED  FOR  FUTUPE  USE 

FLPGM 

DS 

CL8 

READ/HPITE  ACCESS 

FLMGTERM 

DS 

CL70 

OPTIONAL  MSG  'TO  TERMINAL  OPERATOR 

FLMGCON 

DS 

CL70 

OPTIONAL  MSG  TO  CONSOLE  OPERATOR 

FLMEM 

DS 

CL8 

MEMBER  NAME 

7. 14.6 

File  Open 

: Conseguence  of  Return  Codes 

Upon  return  from  the  user  written  validation  subroutine 
register  15  of  the  one  character  cell  designated  by 
parameter  three  can  contain  a hex  0,1,2,  or  3.  Return  codes 
of  1 or  2 will  be  treated  as  0 until  read  only,  write  only, 
and  limited  access  capabilities  are  implemented. 

A return  code  of  0 indicates  that  the  terminal  user  has 
rightful  access.  The  first  byte  returned  in  PLACES  will  be 
either  R (read),  W (write),  or  B (both).  This  value  is 
stored  in  the  MCT  and  can  be  checked  at  a later  time  to 
control  read/write  access  to  the  NIPS  file.  The  second  byte 
returned  in  PLACES  will  be  either  A (all)  or  H (member)  if 
the  data  set  being  validated  is  a library.  Validation  of 
members  is  done  on  an  exception  bases:  if  A is  specified  all 
members  in  the  library  have  the  same  access  code  and  no 
additional  validation  is  performed  when  specified  members 
are  referenced.  In  QUIP,  no  further  checking  of  file  access 
is  performed,  in  SODA,  the  R/W/B  indicator  is  checked  at 
file  update  time,  in  VIEW  and  FOP  MATTER , the  A/M  indicator 
is  checked  at  library  open  time  to  determine  whether  further 
validation  is  required  on  a member  name  bases. 

A return  code  of  3 indicates  that  the  terminal  user  does 
not  have  rightful  access  to  the  data  file  and  the  TP 
application  program  is  terminated  immediately.  The 
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standard  message  APPLICATION  PROGRAM  TERMINATED  DUE  TO 
INVALID  ACCESS  is  written  out  immediately  to  the  terminal 
user,  and  followed  by  an  optional  message  if  specified  in 
the  FLMGTER M area.  In  addition  the  optional  message  defined 
by  FLMGTERM  may  be  used  by  the  TP  application  program  to 
format  error  messages.  The  standard  message  of  TERMINAL 
xxxxxxxx  UNAUTHORIZED  TO  ACCESS  FILE  xxxxxxxxxxx  (maximum  of 
44  characters)  is  written  out  to  the  console  operator  as 
well  as  an  optional  message  is  specified  in  the  FLMGCON 
area. 


7.14.7  Interface  with  TP  Component 

program  modifications  to  both  TP  Monitor  and  TP 
Supervisor  routines  were  required  to  provide  the  necessary 
linkage  needed  to  interface  with  an  installation  validation 
subroutine.  TPPECORD,  the  routine  which  processes  the  input 
line  and  generates  the  accounting  data,  provides  the 
interface  to  the  installation  validation  subroutine  at 
terminal  LOGON  time.  A new  subroutine  function  in  the 
TPSUPEX  routine  was  provided  to  interface  with  the 
installation  validation  subroutine  at  file  open  time.  In 
QUIP,  no  further  checking  of  file  access  is  performed;  in 
SODA  the  R , W , B indicator  is  checked  at  file  update  time. 

An  overview  of  the  LOGON  validation  processing  by 
TPfcECORD  is  oiven  in  figure  1. 

An  overview  of  the  file  access  validation  processing 
done  in  TPSUPEX  is  given  in  figure  2. 

An  example  of  a LOGON  and  file  access  validation  routine 
is  given  in  figure  3. 


7.14.8  Console  Operator's  Control  of  Enabling  and 
Disabling  Terminals 


The  console  operator  can  place  terminals  allocated  to 
NIPS/TP  in  an  active  or  inactive  status  by  replaying  to  the 
NIPS  TP  outstanding  request.  The  outstanding  request  is: 
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nn , TP  STANDING  REQUEST.  REPLIES  ARE  'ENA*  'DISA'  'MSG' 

• PRTY ' 'TPS'  OR  'TPM' * 

If  ENA  is  specified  it  must  be  followed  by  the  designation 
of  ALL  or  the  nane  of  the  terminal  to  be  enabled.  More  than 
one  terminal  name  nay  be  specified  by  enclosing  the  nane 
list  in  parenthesis.  Upon  successful  completion  of  the 
reguest,  the  status  message  TERHINAL(S)  ENABLED  is  sent  to 
the  console  operator  and  the  advisory  nessage  TERMINAL 
ENABLED  - ENTER  LOGON  is  issued  to  the  terminal.  If  DISA  is 
specified  it  nust  be  followed  by  the  designation  of  ALL  or 
the  name  of  the  terminal  to  be  disabled.  More  than  one 
terminal  nane  nay  be  specified  by  enclosing  the  nane  list  in 
parenthesis.  Upon  successful  conpletion  of  the  reguest,  the 
status  message  TERMINAL (S)  DISABLED  is  sent  to  the  console 
operator  and  the  advisory  message  TERMINAL  DISABLED  UNTIL 
FURTHER  NOTICE  is  issued  to  the  terminal.  When  a terminal 
is  in  an  inactive  status,  any  attempt  to  enter  data  by  the 
terminal  user  will  result  in  the  appearance  of  the  following 
message:  NO  INPUT  ALLOWED  - TERMINAL  IS  IN  DISABLED  STATUS. 
When  NIPS/TP  is  initialized  all  terninals  defined  in  the  JCL 
run  deck  are  considered  to  fce  active. 
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Figure  2.  File  Open  Validation  With  Installation  Validation 
Subroutine 
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TITLE  • VAL^FST  - SAMPLE  VALIDATION  SUBROUTINE’ 

THIS  SOUTINE  ILLUSTRATES  HOW  AN  INSTALLATION  ROUTINE  COULD 
CONTROL  RIGHTFUL  ACCESS  TO  TP  TEPMINA  L DEVICES  AND  DATA 
FILES 

UPON  ENTRY  REG  1 = ADDR  OF  PARAMETER  LIST 
PARAMETER  LIST  CONTAINS 
ADDR  OF  SUBSIIP 

HO  BYTE  INPICATOP  FOR  LOGON  OR  FILE 
ADDR  OF  USER  INFORMATION 


* 

4 

ADDR 

OF  PET UP  N CODE  CELL  (1  CHAPACTEP) 

VALTEST 

CSECT 

FFSENTEP 

VALTEST 

BALE 

2,0 

USING 

*,  2 

LR 

6,1 

PICK-UP  PARAMETER  LIST 

USING 

P AR  MLI ST  , 6 

CL  I 

P2CODE,C’L* 

LOGON  VALIDATION 

BE 

LOGON 

YES-BPANCH 

CLI 

P2CODE , C • F* 

FILE  ACCESS  VALIDATION 

BE 

FILF 

YES-BPANCH 

LA 

15,16 

SET  RETUFN  FOP  INVALID 

B 

RETURN 

• 

LOGON 

EQU 

* 

L 

7, P2CODE 

PICK-UP  USER  LOGON  IN^O 

USING 

TPLGDEE, 7 

LA 

8, LGDATA 

STAPT  ADDR  OF  LOGON 

LA 

9,70 

LENGTH  OF  SCAN 

SCAN 

CLI 

0(8), C’  • 

TEST  FOR  BLANK 

BN  E 

CHARFIND 

NO-BRANCH 

LA 

8,1  (8) 

BUMP  TO  NEXT  CHARACTER 

BCT 

9, SCAN 

DFCPEMENT  LOOP  COUNTER 

B 

ERR1 

NO  INFO-TREAT  AS  ERROR  LEVEL  1 

CHARFIND 

CLI 

0 (8)  ,cn  • 

TEST  FOR  ALPHA 

BL 

ALPHA 

YES-BRANCH 

B 

EPF2 

NUMERIC  CHAR ACTEPS- ERROR  LEVEL 

ALPHA 

LA 

4, N AMETAB 

LOAD  NAME  TABLE 

LA 

5,4 

NUMBER  OF  ENTPIES 

LOGLOOP 

CLC 

0(6,8)  ,0(4) 

Figure  3. 

LOGON  and 

l File  Access 

Validation  Routine  (Part  1 of  3) 

14.1 


INSTALLATION 


MATCH 

LH  R 1 

EBP  2 

EBR3 

FILE 


MEMOK 

OLDWAY 

Piqute 


BE 

LA 

BCT 

li 

M VC 

SB 

B 

EUU 

M VC 
LA 

B 

EQU 

MVC 

LA 

B 

EQU 

MVC 

MVC 

LA 

B 

EQU 

L 

USING 

CLC 

BE 

MVC 

MVC 

CLC 

BN  E 

CLC 

BN  E 

MVC 

LA 

B 

MVC 

SB 

B 

EUU 


MATCH 
4, 10  (4) 

5, LOGLOOP 
SPP3 

LGCODE  , 6 (4) 
15, IS 
RETURN 


BUMP  TO  NEXT  ENTRY 

NOT  IN  NAME  TABLE-ERPOR  LEVEL  3 
MOVE  LOGON  ENCODED  VALUE 
SET  PETUPN  CODE  TO  ZERO 


LGMGTERM  (28)  , = C' OPTION AL  MSG  - ERPOR  LEVEL  V 
15,1  SET  PETUPN  CODE  TO  ONE 

PETUPN 


LGMGTERM  (20)  , = C' OPTIONAL  MSG  - E^BOP  LEVEL  2' 
15,2  SET  RETUPN  CODE  TO  TWO 

RETUPN 


LGMGTERM  (28)  ,=C'OPTIONAL  MSG  - ERROR  LEVEL  3* 

LGMGCON  ( 38) , =C 'OPTIONAL  LOGON  MSG  TO  CONSOLE  OPSRATOP' 

15,3  SET  PETUPN  CODE  TO  THREE 

RETUPN 

* 

7.P2CODE  PICK-UP  FILE  OPEN  INFO 

TPFLDE", 7 

PLLGCODE,=C' ALOK*  CHECK  FOF  SYS  MRG  ACCESS  CODS 
FM ATCH 

TEMP  WK ♦ (4) , FLLGCODE 
TS  M P WK  * 4 (7)  , FLNAMF 
FLNAM5  (7)  ,=C' SCI  DATA • 

OLDWAY 

FLMEN  (6)  ,=C*  SITR  EP ' 

MEMOK 

FLHGTEPM  (3H0,  =C'ACCESS  NOT  ALLOWED  THIS  MEMBER' 

1^,3 

RETURN 

PLACES, vC'PM  • 

15,15 

RETURN 


. LOGON  and  "ile  Access  Validation  Routine  (Part  2 of  3) 


144 


INSTALLATION 


LA 

4, FILETAB  LOAD  FILE  TABLE 

LA 

5,9  LOAD  FILE  TABLE 

FILBLOOP 

CLC 

TEHPWK ,0  (4) 

BE 

?1 HATCH 

LA 

4,16(4)  BUMP  TO  NEXT  ENTRY 

BCT 

5, FILFLOOP 

nvc 

FLHGTERH  (33)  , = C'OPTIONAL  MSG  FROM  FILE  VALIDATION* 

nvc 

FLMGCON ( 35) , =C*OPTIONAL  FILE  ACCESS  MSG  TO  CONSOLE* 

LA 

15,3  SET  RETUPN  CODE  TO  THREE 

B 

RETURN 

FMATCH 

MV  C 

PLACES, =C'BALL • 

B 

RET1 

P1MATCH 

nvc 

FL ACFS ,12  (4)  HOVE  FILE  ACCESS  CODE 

BET  1 

SR 

15,15 

RETURN 

FFSEXIT 

RC= (15) 

TEMPWK 

DC 

CL  1 1 ' • 

NAflETAB 

DC 

C* BROWN  LGAA • 

DC 

C*  JONES  LGBB • 

DC 

C'SHITH  LGBC* 

DC 

C'SYSMGR  ALOK* 

FILETAB 

DC 

C'LGAATFSTER  RFLA ' 

DC 

C ' LG AATP  AINER  RFLA* 

DC 

C' LGAAMFNUDATAR A • 

DC 

C*  LGAASCIDATA  RH  » 

DC 

C*  LGBBTESTER  WFLB • 

DC 

C'LGBBTP AINER  BFLB  * 

DC 

C*  LGBBXTFST  RFLB* 

DC 

C' LGBBHESTER  R*LB* 

DC 

C*  LGCCTR  AINER  RFLB' 

PAfiflLIST 

DSECT 

Pi ADDR 

DS 

A 

P2CODE 

DS 

CL1 

P2 ADDR 

DS 

AL  3 

P3ADDR 

DS 

QTPFLDEF 

QTPLGDSP 

END 

A 

Figure  3. 

LOGON  and 

File  Access  Validation  Routine  (Part  3 of  3) 

145 


INSTALLATION 


7.15 


TPQUIPVS  Load 


structure 


for  QUIP 


QUIP  is  unique  program  in  the  NIPS  TP  component  in  that 
by  choosing  the  QUIP  load  structure  for  the  installation  it 
is  possible  to  tailor  the  Monitor  and  Supervisor  generation 
to  the  resources  available  and  the  user  requirements  for 
query  response  time. 


The  distributed  TP  Moni 
to  use  the  TPQUIP  load  str 
used  most  commonly  since  it 
quite  some  time.  In  th 
consists  in  a number  of  dis 
sizes,  which  are  linked  to 
during  translation  and  exec 
allows  QUIP  to  execute  with 
since  only  routines  neces 
brought  into  core,  and  then 
The  disadvantage  of  this  st 
load  and  delete  the  various 


tor  and  Supervisor  are  generated 
ucture  for  QUIP.  This  is  the  one 
was  the  only  one  available  for 
e TPQUIP  load  structure,  QUIP 
tinct  load  modules,  of  various 
or  loaded  and  called  as  required 
ution  of  a query.  This  structure 
a minimum  of  core  requirements 
sary  for  the  particular  query  are 
only  for  the  duration  of  use. 
ructure  is  the  overhead  needed  to 
modules  as  they  are  used. 


The  TPQUIPVS  load  structure  has 
eliminate  that  overhead  for  certain  types 
the  QUIP  load  modules  which  process 
LIMIT,  retrieval  IP,  LIST,  and  LOAD  have 
a single  load  module  to  make  them  core  r 
as  at  least  one  QUIP  user  is  signed 
overhead  reductions  are  also  possible 
process  other  operators  since  all  the  loa 
required  for  the  execution  of  every  quer 
included  in  the  TPQUIPVS  structure. 


been  designed  to 
of  queries.  All 
the  QUIP  operators 
been  combined  into 
esident  for  as  long 
on.  Significant 
for  queries  which 
d modules  which  are 
y have  also  been 


By  designating  the  TPQUIPVS  load  structure  for  QUIP  it 
is  possible  to  achieve  automatic  reduction  in  QUIP  setup 
time  (i.e.,  the  elapsed  time  in  QUIP  from  the  start  of  the 
query  to  the  start  of  file  search)  as  compared  to  the  time 
obtained  with  the  TPQUIP  structure.  Therefore,  if  queries 
can  be  designed  so  that  record  qualification  and  data  output 
begin  with  the  start  of  file  search  (e.g.,  the  LIMIT 
operator  restricts  retrieval  to  those  records  which  contain 
data  to  be  displayed),  improved  response  time  will  be 
obtained  for  the  time  the  first  page  of  data  is  received  on 
the  CRT.  Additional  improvement  is  possible  when  the 
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i INCORFFT  option  is  specified  for  QUIP  in  TP  Supervisor 

generation  (see  section  7.5,  TP  Supervisor  Generation). 
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This 

message 

defaults 


A. 1 TPQ 

//TP  Q 

// 

//DD1 

// 

//DD2 

// 

//DD3 

// 

//DD4 

// 

//DDt> 

// 

//DD6 

// 

//DD7 

// 

//DD8 

// 

//DD9 

// 

//DD1 0 

// 

//DD11 

// 

//DDL2 

// 

//DDE3 

// 

//DDE4 

// 


Appendix  A 

ALLOCATION  OF  TP  MESSAGE  QUEUES 


appendix  provides  sample  JCL  to  allocate  the 
queues  required  by  TP.  The  JCL  reflects  the 
names  for  the  Output  Message  Queues. 


Job 


JOB 

EXEC 

DD 

DD 

DD 

DD 

DD 

DD 

DD 

DD 

DD 

DD 

DD 

DD 

DD 

DD 


PGN  = 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 
DSNAME 
VOLUME 


IEFBR14 
=TPIHQ, DISP 
=SER=FFSLIB 
= T. DD52  250 A 
=SER=F?SLIB 
= T. D512250A 
=SER=FFLIB, 
=T . DD  62  260A 
=SER=FF  SLIB 
= T. DD62  260  B 
=SER=FF  SLI B 
= T. DD62260C 
=SER=FFSLIB 
=T . DD62  260D 
=SER=FFSLIB 
=T. DD62  260E 
=SER=FF  SLIB 
=T. DD62260F 
=SEP=FFSLIB 
-T. DD62  260G 
=SER=PFSLIB 
= T.  DD62260H 
=SER=FFSLIB 
= E. DD  52  250A 
=SER=PPSLIB 
= E. DS12  250A 
SER=FFLIB# 
E.DD62260A 
SER=FPSLIB 


= (NEH, 
, S PACE 
, DISP= 
# SPACE 
,DISP= 
SP  ACE= 

# DISP= 
, SPACE 

,DISP= 

, SPACE 
,DISP= 
, SPACE 
, D ISP= 

# SPACE 
, D IS  P= 
, SPACE 
, DIS P= 
, SPACE 
,DISP= 
, SPACE 
,DISP= 
, SPACE 
,DISP= 
, S PACE 
,DISP= 
SPACE* 
, DISP* 

# SPACE 


CATLG)  ,UN 
=(80,501) 
(NEW,  KEEP 
= (TPK,  (20 
(NEW, KEEP 
(TRK,  (20) 
(NEW, KEEP 
= (TPK,  (20 
(NEW,  KEEP 
= (TRK,  (20 
(NEW, KEEP 
= (TRK,  (20 
(NEW, KEEP 
= (TRK, (20 
(NEW, KEEP 
= (TPK,  (20 
(NEW, KEEP 
* (TPK,  (20 
(NEW, KEEP 
= (TRK,  (20 
(NEW, KEEP 
* (TPK,  (20 
(NEW, KEEP 
=(TPK, (20 
(NEW, KEEP 
(TPK,  (20) 
(NEW, KEEP 
= (TRK,  (20 


IT=231 


, UNIT 


, UNIT 
, UNIT 
, UNIT 
, UN  IT 
,UNIT 
, UNIT 
, UNIT 
, U NIT 
, UNIT 
, UNIT 
, UNIT 
, UNIT 


=2314, 

=2314, 

=2314, 

=2314, 

=2314, 

=2314, 

=2314, 

=2314, 

*2314, 

=2314, 

=2314, 

=2314, 

=2314, 


148 


INSTALLATION 


//DDE5 

// 

DD 

//DDE6 

// 

DD 

//DDF7 

// 

DD 

//DDES 

// 

DD 

//DDE9 

// 

DD 

//DDL10 

// 

DD 

//DDE11 

// 

/* 

DD 

DSNAME=E. DD62260B,  DISP=  (NEW  , KEEP) 
VOLUME=SER=FPSLIB,SPACE=  (TRK,  (20) 
DSNA  ME=E. DD62  260C, DISP= (NEW , KEEP) 
VOLU  HE=SER=FFSLIB,S  PACE= (TRK,  (20) 
DSNA  ME=E.  DD62  260D,  DISP=  (NEW  , KEEP) 
VOLUME=SER=FPSLIB,SPACE= (^PK,  (20) 
DSNAMS=E.DD62260E,DISP= (NEW, KEEP) 
VOLUME=SER=F?SLIB, SPACE= (TRK,  (20) 
DSNAHE=E.DD62  260P,  DISP=  (NEW,  KEEP) 
VOLUME=SER=FFSLIB,SPACE= (TPK, (20) 
DSNAME=E.DP62260G,DISP=  (NEW,  KEEP) 
VOLU.1E=SEP=FFSLIB,SPACE=  (TPK,  (20) 
DSNA  ME=E.  DD62  260H, DISP= (NEW, KEEP) 
VOLUH  E = SER=FPSLIB,S  PACE= (TPK,  (20) 


, fJNI  T = 231 4, 
) 

, UNIT=231 4, 
) 

, UNIT=2  31  4, 
) 

, UNIT=2314, 
) 

, UNIT  = 2 31 4, 
) 

,UNIT=231 4, 
) 

, 0NIT=2314, 
) 


149 


INSTALLATION 


Appendix  B 

TYPICAL  INSTALLATION  PROCEDURE 


This  appendix  provides  more  specific  information  to  the 
systems  programmer  who  intends  to  install  NIPS  360  FFS  at  a 
new  installation.  It  suggests  a sequence  of  steps  to 
install  the  system  and  describes  the  jobs  to  be  performed  at 
each  step.  JCL  examples  for  the  jobs  discussed  are  found  in 
appendix  C.  It  is  intended  that  this  typical  procedure  mill 
provide  additional  insight  by  illustrating  the  type  of  JCL 
required  to  install  NIPS  360  FFS. 


B.  1 Clip  Dish  Pack  to  FFSLIB 

Run  the  PACKLABL  job  in  the  Installation  Package  to 
provide  a disk  pack  labeled  FFSLIB.  If  the  IEHDASDR  Utility 
program  is  not  available,  run  a stand-alone  CLIP  program. 
To  allow  a minimum  amount  of  changes  to  the  JCL  for  the  jobs 
in  the  Installation  Package,  all  references  to  disk  space 
mere  made  mith  a UNIT=2314  and  VOLU ME=S ER  = FFSLI B. 

Ideally,  if  one  scratch  pack  can  be  reserved  for  this 
purpose,  installation  and  testing  of  the  FFS  system  can  be 
performed  in  the  most  optimum  manner  since  the  sample  JCL 
assumes  a pack  labeled  FFSLIB.  After  installation,  the 
system  data  sets  can  always  be  moved  to  other  packs  and 
recataloged,  returning  this  pack  to  the  installation.  The 
scratch  pack  is  assumed  to  be  a 2314. 
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B.  2 Catalog  System  Data  Sets 

To  minimize  the  amount  of  JCL  required  in  subsequent 
jobs,  the  following  data  sets  are  cataloged  to  FFSLIB  using 
the  CATLG  job: 

FFS. JOBLIE 
FFS. JOBMACRO 
FFS. PROCLIB 
PTF. JOBLIE 
PTF. JOBMACRO 
TESTERL 
DUMM I.  FILE 
DUMMY. FILEL 
DUMMY. FILES 
DUMMY. FILEX 

The  unit  type  for  the  pack  labeled  FFSLIB  is  assumed  to  be 
a 2314.  The  data  sets  DUMMY. FILES  and  DUMMY. FILEX  are 
cataloged  to  the  pack  labeled  FFSLIB.  These  data  sets  are 
necessary  tor  Procedures  JCL  resolution  but  are  never 
actually  used. 


B. 3 Restore  System  Data  Sets 

The  following  data  sets  must  be  loaded  to  direct  access: 

FFS. JOBLIB 
FFS. JOBMACRO 
FFS. PROCLIB 
PTF. JOBLIB 
PTF. JOBMACRO 
DUMMY. FILEL 
TESTERL 

The  data  set  FFS. PROCLIB  is  restored  to  update 
SYS1. PROCLIB  and  can  subsequently  be  uncataloged  and 
scratched.  TESTERL  is  only  needed  to  run  the  sample  jobs. 

If  the  system  data  sets  were  received  on  a dump/restore 
tape,  the  restore  operation  becomes  relatively  simple.  The 
RESTORE  job  will  load  all  data  sets  onto  FFSLIB  for 
installations  having  the  IEHDASDR  ntility  program. 
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If  the  system  data  sets  were  received  as  sequential  and 
unloaded  partitioned  data  sets,  space  is  allocated  for  each 
data  set  on  FFSLIB  and  the  data  sets  reloaded  to  the  pack. 
The  RELOAD  job  should  accomplish  this  task.  This  job  is  set 
up  for  a 2314  reload;  if  2311's  are  being  used,  triple  the 
primary  allocation  for  each  data  set  (except  DUMMY. PILEL)  . 


B.  4 Update  SYSl.PROCLIB 

The  COFYPROC  job  could  be  used  to  place  the  FPS 
procedures  in  the  SYSl.PROCLIB.  If  a source  copy  of  the 
procedures  is  desired,  the  IEBPTPCH  Utility  program  will 
punch  a copy  of  these  procedures.  An  IEBUPDTE  Utility 
program  could  then  place  the  procedures  into  the 
SYSl.PROCLIB  with  the  punched  cards  as  input. 

The  distributed  procedures  must  be  modified  at  some 
installations.  For  example,  if  the  operating  system  at  an 
installation  has  been  generated  for  UNIT  values  other  than 
NIPH,  TAPE9  and  TAPE7 , the  procedures  should  be  modified  to 
conform  to  installation  conventions.  The  procedures  can  be 
punched  out  from  FFS.PROCLIB,  modified,  and  then  placed  on 
SYSl.PROCLIB.  They  can  also  be  changed  on  FFS.PROCLIB  and 
then  moved  to  SYSl.PROCLIB  with  the  IEBUPDTE  utility 
program. 


B. 5 Run  the  Sample  Job 

The  sample  job  is  distributed  as  an  unblocked  card  image 
data  set.  This  partitioned  data  set  is  prepared  with  the 
sample  jobs  in  the  sequence  suggested  in  Section  3.9,  Sample 
Jobs  Library.  The  data  file  created  by  the  PPTJOB  job  will 
be  placed  on  the  same  disk  pack  that  the  Sample  Subroutine 
Library  (TESTERL)  resides. 

The  TESTERL  library  also  contains  subroutines  developed 
by  other  installations.  These  subroutines  are  distributed 
with  the  NIPS  system  as  they  may  be  of  use  to  other  NIPS 
users.  If  these  subroutines  are  being  used,  the  TESTERL 
library  should  not  be  scratched. 


I 

t* 
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The  following  JCL  »ay  be  used  to  punch  out  the  sample 
job  JCL  statements: 

//SAMPLJOB  JOB 

//PUNCH  EXEC  PGM=IEBGENER 

//SYSPRINT  DD  SYSOUT=A 

//SYSUT1  DD  DIS P=OLD, DS  N=NIPS .SAMPLE. JOB ( BLDJCL) 

//SYSUT2  DD  SYSOUT=B 

/* 

Each  job  of  the  sample  jobs  tape  has  a job  card  with  the 
following  format: 

//JOBNAME  JOB, HSGLE VEL= 1 , PRT Y=NN 

If  the  installation  requires  specific  accounting 
information,  the  sample  jobs  can  be  modified  and  run 
individually  in  the  sequence  suggested  by  the  priorities 
assigned  to  each  job. 

The  JCL  required  to  create  the  NIPS  system  is  contained 
in  appendix  C.  The  JCL  is  distributed  on  the  system  tape  as 
a sequential  data  set  consisting  of  card  images.  The  OS 
utility  I EBGENER  may  be  used  to  punch  this  data  set,  so  that 
the  JCL  can  be  modified  to  reflect  installation  and/or 
system  requirements.  The  following  job  may  be  used  to  punch 
the  installation  JCL: 

//NIPSJCL  JOB 
//PUNCH  EXEC  PGM=IEBGENFR 
//SYSPRINT  DD  SYSOUT=A 
//SYSUT1  DD  DIS  P=OLD, DS  N=NI PS JCL 
//SYSUT2  DD  SYSOUT=B 
//SYSIN  DD  DUMMY 
/* 
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Appendix  C 

TYPICAL  INSTALLATION  JCL 


In  the  following  JCL  examples,  the  JCL  statements  begin 
in  card  column  1,  the  continuation  character  X is  assumed  to 
be  in  card  column  72,  and  all  continuation  cards  begin  in 
card  column  16. 


C.1  PACKLABL  Job 


This  job  will  provide  a volume  serial  number  of  PFSLIB 
to  a 2314  dish  pack  currently  labeled  XXXXXX.  It  is 
recommended  that  this  pack  be  initialized  (DASDI)  before 
using  as  a NIPS  360  FFS  system  pack. 

If  the  IEHDASDR  Utility  program  is  not  available  with 
the  current  release  of  your  Operating  System,  a stand-alone 
CLIP  program  could  be  used. 


//PACKLABL  JOE 
//GO  EXEC 

//SY3PBINT  DD 
//DISK  DD 

// 

//SYSIN  DD 

LABEL 


PGM=IEHDASDR 
SYS0UT=  A 

DISP=OLD,UNIT= (2314,, DEFER)  , 
V0LUME=  (PRIVATE, ,SER= (XXXXXX)  ) 
*,DCB=BLKSIZE=80 
TOD D= DISK, NEW VOLID=FFSLI B 


/* 
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C. 2 CATLG  Job 

This  job  will  catalog  NIPS  360  FFS  data  sets  to 
disK  pack  labeled  FF3LIB. 


2314 


//CATLG 

//GO 

//SYSPRINT 

//SYSTEM 

//SYSIN 

CATLG 

CATLG 

CATLG 

CATLG 

CATLG 

CATLG 

CATLG 

CATLG 

CATLG 

CATLG 

CATLG 

CATLG 

/* 


JOB 

EXFC  PG  M= IEHPROGM 

DD  SYSOMT=A 

DD  DSNAME=SYS1.SVCLIB,DISP=OLD 

DD  *, DCE=BLKSIZE=80 

DSNAME=FFS. JOBLI8, VOL =2 3 1 4= FFS LI B 
DSNAME=FFS. JOBM ACPO, V0L=2314=FFSLIB 
DSNA1E  = FFS.T,0OCLIB#VOL=2314=FFSLIB 
DSNAME=PTF. JOBLIB=VOL=2314=FpSLIB 
DSNANE=PTF. JOBH AC°0, VOL=231  4 = FPSLIB 
DSNAHE=TES72°L, VOL= 2 3 1 4=FFS LI B 
DSNANE= DUMMY. PIIE,V0L=2314=FFSLIB 
DSNAME= DUMMY. FILEL, VO L=23 1 4 =F F SLI B 
DS NAME = DUMMY. FI LES , VO L= 23 1 4 = FFS LI B 
DSNAME  = DUMMY. FI  LEX, VOL=2314=FFSLIB 
DSNAMP=DU  MMY.  I S AMFI LE , VOL= 2 31 4=C ANCEL 
DSN  AME=  DUM  M Y.  S A NFILE , VOL=2 3 1 4 =CA NCEL 


Note:  DUMMY. ISAMFILE  and  D UMM Y. S AM  FILE  are  not  required  to  be 

cataloged  if  there  is  no  TP  support. 


C. 3 RESTORE  Job 

This  job  will  restore  all  NIPS  360  ”S  data  sets  to  a 

2314  disk  pack 

labeled  PFSLIB . It  should  be  used  with  the 

IEHDASDB  Utility 

prog 

ran. 

//RESTORE 

JOB 

// 

EXEC 

PGN=IEHDASDR 

//SYSPRINT 

DD 

SYSOt|T=A 

//TAPE 

DD 

DSNAME=FFS360,DISP=OLO, 

// 

LABEL=(,SL)  , DCB=D EN  = 2, 

// 

tTNIT=  (2400,  , DEFER)  , VOL=  (PR I V AT E , , S ER=  (FFS  360) 

//DISK 

DD 

UNIT=2  314,  VOL*SEP=PFSLIB,DISP  = OLD 

//SYSIN 

DD 

* 

RESTORE 

TODD=DISK, FROM DD*T APR, PURGE=YES 

/* 
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C.4  RELOAD  Jot 


This  job  will  restore  the  NIPS  360  eFS  data  sets  that 
are  distributed  as  unloaded  partitioned  and  sequential  data 
sets.  The  Skeleton  File  Library  DUMMY. FILEL  is  created  but 
no  data  is  moved  into  this  data  set. 


//RELOAD 

JOB 

//ALLOCATE  EXEC 

PGM=IEFBR14 

//DD1 

DD 

DSNAME^FS.  JOBLIB,  DISP2  (,  KEEP)  , UNIT=2314, 

// 

S PACE=  (CYL, (30,  5, 50) ) , VOLUME  = SER  = FFS LIB, 

// 

DCB=  (BLKSTZF.27294,REC?M2U) 

//DD2 

DD 

DSNAME=FFS.JOBMACPO,DISP2 (, KEEP) , UNIT=2314, 

// 

S PACE  = (CYL, (10, 5,50) ) , V OLUM E2 SER=F FSLI B, 

// 

DCB=  (BLKS IZF23360,LRECL=80,RECFM=FB) 

//DD3 

DD 

DSNAME=PTF. JOBLIB, DISP= ( , KEE  P) ,UNIT=2314, 

// 

SPACE'2  (CYL,  (10, 5,50)  ) , VOL=SEP=FFSLIB, 

// 

DCB=  (BLKSIZE  = 7294,PECFM  = U) 

//DD3A 

DD 

DSNANE  = PTF.JOBMACPO,DISP=(,KEEP)  , UNIT=2314 , 

// 

S PACE2 (CYL , (2,2,10) ) , VOL=SEP2PFSLI B, 

// 

DCB=  (BLKSIZE=3  3 60) , LR  ECL=80 , R ECF M = FB 

//DD4 

DD 

DSNAME2FFS.PROCLIB,  DISP2  (,  KEEP)  , UNIT  = 2314, 

// 

SPACE2  (CYL,  (5,  1,50))  , VOL  UHE=SER=FFSLIB, 

// 

DCB=  (BLKSIZE=60 , LRECL=80 ,PECFM=FB) 

//DD5 

DD 

DSNAME=TESTERL, DISP2 ( , KEEP) ,UNIT=2314, 

// 

S PACE2 (CYL, (2,2,10))  , VOLUME=SER2FFSLIB, 

// 

DCB2  (BLKSIZE=7294,PECFM2U) 

/,  DD6 

DD 

DSNAME2DUMMY.FILEL,DISP=  (,  KEEP)  , UNIT22314, 

// 

SPACE2 (CYL, (1,1,1)) ,VOLUHE2SEP=FFSLIB, 

// 

DCB2  (BLKSIZE=7294,PECFM=U) 

//LOAD 

EXEC 

PGM=IEHMOVE 

//SYSPRINT  DD 

S YSOUT=A 

//SYSUT1 

DD 

DISP2OLD,UNIT22314,VOLUME2SEP=FFSLIB 

//DD  1 

DD 

DISP2 OLD, UNIT2  2314,V0LUHE=SER2FESLIB 

//TAPIN 

DD 

DSNAHE=FFS360,UNIT224  00,DISP2 (,KEEP)  , 

// 

LABEL2(1,SL) , VOLUME=SER2FFS360, 

// 

DCB=(RECFM2FB,LRECL280, BLKSIZE2800,DEN=2) 

//SYSIN 

DD 

*,DCB=BLKSIZE280 

COPY 

PDS  = FFS 

.J0BLTB,T022314=FFSLIB, FPOM22400= (FFS360,1) 

COPY 

PDS2  F FS 

. JOBM ACRO ,TO=2  31 42*FSLIB,FROH  = 24002  (FFS360,2) 

X 

X 

X 

X 
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COPY  PDS=FFS.PROCLIB,TO=231  4=  FFSLIB  , FROM=2400=  (FFS360,3) 

COPY  PDS=TESTERL,TO=2314=FFSLIB,FROM=2400= (FFS360,4) 

COPY  PDS= NIPS. SAMPLE. JOE, TO=2 31 4=FFSLIB, FROM=2400=  (PFS360,5) 
COPY  PDS-PTP.JOBLIB,TO=2314=  FFSLIB, FFOM=2400= (FFS360,6) 

COPY  PDS=PTF.JOBMACRO, TO=23 1 4-=F  FS  LIB, FRO  M=  2400  = (FFS360,7) 


C. 5 COPYPROC  Job 


This  job  will  update  SYSl.PROCLIB  from  the  NIPS  360  FFS 
data  set  named  FFS.PROCLIB.  The  data  set  resides  on  a 2314 
disk  pack  labeled  FFSLIB  and  is  assumed  to  be  cataloged. 


//COPYPROC 

//GO 

//S YSPRI NT 
//SYSUT1 
// 

//SYS0T2 
//SYSIN 
./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 


JOB 

DD 

DD 

DC 

DD 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPF.O 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 

REPRO 


EXEC  PGM=IEBUPDTE,PARM=MOD 

SYSOOT=A 

DSNAHE=FFS.PPOCLIB,DISP=OLD, UNIT=2314, 

VOLUME=SFR=FFSLIE 

DSNAME=S YS1 . PPOCLIB, DI SP=OLD 

*, DCB=BLKSIZE=80 

LEVEL=00,SOURCE=0,LIST=ALL, NAMF=XFFSPTFL 
LEVEL  = 00, SOUFC  E=0, LI ST  = ALL, NAME=  XFM 
LEVEL  = 00  ,SOUPCE=0,LIST=ALL, NAME  = XFMEX 
LEVEL=00, SOUFC E=0,LIST= ALL,  NAME=XFR 
LEVEL=00,  SOI1RCE=0,  LI  ST  = ALL,  NAME=XFS 
LEV  EL=00 , SOUPCE=0,LIST=ALL,NAME=XISTOS 
LEVEL=00,SOURCE=0,LIST=ALL, VAME=XOP 
LEVEL=00, SOUPCE=0,LIST= ALL, NAME=XOPEX 
LEVEL=00,SOURCE=0,LIST=ALL, NANE=XOPSD 
LEVEL=00,SOU«CE=0,LIST=ALL,  NAME=XOPSPEX 
LEVEL=00,SOURCE=0,LIST=ALL, NAME=XPASP 
LEVEL=00,SOURCE=0, LIST=  ALL, N AME  = X FASPEX 
LEVEL=00 , SOURCE=0, L I ST = ALL, NAME=XSTOIS 
LEVEL=00,SOUPCE=0,LIST=ALL, NAME=XSUBLDR 
LEVEL=00,SOURCE=0,LIST=ALL,  NAME=XTABGEN 
LEVEL=00,SOURCE=0,LIST=ALL,NAME=XQUIP 
LEVEL=00 ,SOURCE=0,LIST=ALL, N AHE=XQUIPSD 
LEVEL=00  , SOUPCE=0, LI ST = ALL, NAME=XQRTQDF 
LEVEL=00  ,SOURCE=0,LIST=ALL,  N AHE=X SAVEANS 
LEVEL=00, SOURCE=0,LIST=ALL, NAME=XFESTANS 
LEVEL=00,SOURCE=0,LIST=ALL,NAME=XSAVELTB 
LEVEL=00,  SOUrCEs0f  LI  S'r  = ALL,  NAME=XRES,,,LIB 
LEVEL=00 ,SOUPCE=0, LIST  = ALL,  NAHF  = XDMPLIB 


X 
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./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

./ 

/* 


REPRO  LEVEL=00 , SOUPCE^O,  LIST= ALL,  N AHE  = XSUBCHK 

REPRO  LEVEL=00,SODRCE=0,LIST=ALL,NAME=XCLASS 

BEPRO  LEVEL=00, SOURCE=0, LIST  = ALL, N AHE=XUTFSCAN 

REPRO  LEVEL=00,SOURCE=0,LIST=ALL, NAME=XSP 

REPRO  LEVEL=00,SOURCE=0,LIS?=ALL,NANE=XTRTAPE 

REPRO  LEVEL=00,SOUPCE=0,LIST=ALL#NAME=XTRDISK 

REPRO  LEVEL=00,  SOURCE=0,  LI Sm=ALL,  NAflE=  XTP 

REPRO  LSVEL=00 , SOURCE=0, LIST= ALL, NAHE=TPRDR080 

REPRO  LEVEL=00, SOURCE=0,LIST=ALL,NAME=XKA 

REPRO  IEVEL=00,SOUPCE=0,LIST=ALL, NABE=XKB 

REPRO  LEVEL=00,SOURCE=0,LI ST* ALL,  N ANE=X(JTODE 

ENDUP 


Note:  XTP  and  TPRDR080  need  or.ly  be  included  if  TP  is  required. 
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Appendix  D 

DATA  SET  SPECIFICATIONS 


£4X4-251 

*S£ ACE  BLKSIZE 

LJR  ECL 

RECFH 

FFS. JOBLIB 

(CYL, (30,5,50)) 

7294 

U 

FFS, JOBN ACBO 

(CYC,  (10,5,50)) 

3360 

80 

FB 

FFS . PROCL1B 

(CYL,  (5,1,50)  ) 

80 

80 

FB 

PTF. JOBLIB 

(CYL,  (10,5,  50)) 

7294 

(J 

PTF. JOBN ACBO 

(CYL,  (2,2,10)  ) 

3360 

80 

FB 

TEST2RL 

(CYCL, (2,2, 10) ) 

7294 

U 

BUM HY.FILEL 

(CYL,  (1,1,1)) 

7 29  4 

U 

*2314  cylinders 

Note:  The  FFS 

.JOBLIB,  TESTERL, 

and 

DOHHY.FILEL 

libraries 

should  have  a blocksize  of  7294  if  they  are  to  reside 
on  a 2314  disk  pack  and  a blocksize  cf  3625  if  they 
are  to  reside  on  a 2311  disk  pack. 
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N I°S  360  EPS 

DISCPEPANCY/CHANGE  PEPOP^ 


HaiSSi Date; 

&dd£essi 

NIPS  Component  (si ; NIPS_Releasei 

2£_&£lSi£&i l£il£le_oj15i_PCP-H’X-llVlL 

fi£iS_££2{»i§»_eflcoiin  tered:. 


DCS  Number: 


PhSliei 


Accompanying  Materials 

Core  Dump  JCL  Stream 

Console  List  Other 


Description  of  problem: 


Actions  already  taken: 


Received  by: Date: 

Time:  Turned  over  to:  _ 
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Appendix  ? 

DCR  NUMBER:  

t TAR  NUMBER: 

MAINTENANCE  PROGRAMMER'S  REPORT 


Completed  by: Date: 


Type  of  Problem:  "component  Problem 

User  Problem 

OS  Problem 


Machine  Malfunction 
Other 

Improvement  Suggestion 


V 


DISTRIBUTION 


CCTC  CODES  COPIES 


Cl  24  (Reference  and  Record) 

Cl  24  (Record  Copy)  Stock 

C240  2 

C315 1 

C341  (Maintenance  Contractor) 10 

C34  1 (Stock) 70 

EXTERNAL 

Director  of  Administrative  Services,  Office  of 
the  Joint  Chiefs  of  Staff 

Attn:  Chief,  Personnel  Division,  Room  1A724,  The 
Pentagon  Washington,  D.C.  20301 1 

Director  for  Personnel,  J-1  , Office  of  the  Joint 
Chiefs  of  Staff,  Attn:  Chief,  Data  Service  Office, 
Room  1B738C,  The  Pentagon,  Washington,  D.C. 

20301 1 

Director  for  Operations,  J-3 , Office  of  the  Joint 
Chiefs  of  Staff,  Attn:  P & AD,  Room  2B870,  The 
Pentagon,  Washington,  D.C.  20301 1 

Director  for  Operations,  J-3,  Office  of  the  Joint 
Chiefs  of  Staff,  Attn:  Deputy  Director  for 
Operations  (Ro con nuisance  and  Electronic  Warfare) 
Room  2D921 , The  Pentagon,  Washington,  D.C. 

20301— 1 

Director  for  Logistics,  J-4,  Office  of  the 
Joint  Chiefs  of  Staff,  Room  2E828,  The  Pentagon, 
Washington,  D.C.  20301 1 

Chief,  Studies  Analysis  and  Gaming  Agency,  Attn: 
Chief,  Force  Analysis  Branch,  Room  1D928A,  The 
Pentagon,  Washington,  D.C.  20301 1 

Automatic  Data  Processing,  Liaison  Office 
National  Military  Comma-  1 Center,  Room  2D901A., 

The  Pentagon,  Washington,  D.C.  29  301 1 
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COPIES 


Automatic  Data  Processing  Division 

Supreme  Headquarters  Allied  Powers,  Europe 

Attn:  SA  6 P Branch,  APO  New  York  09055 1 

Director,  Defense  Communications  Agency,  Office 
Of  MEECN  System  Engineering,  Attn :' Code  9 GOT, 
Washington,  D.C.  20301 1 

Director,  Defense  Communications  Engineering 

Center,  Hybrid  Simulation  Facility,  1860 

Wiehl  Avenue,-  Res  ton , VA  22070 1 

Director,  Defense  Intelligence  Agency 
Attn:  DS  - 5C2 

Washington,  D.C.  20301 5 

Commandcr-in-Chief , Pacific,  Attn:  J6331 , 

FPO  San  Francisco,  96610 — 1 


Commander-in-Chief,  US  Army  Europe  and 

Seventh  Army  ATTN:  OPS  APO  New  York  09403 1 

Commanding  General,  US  Army  Forces  Command, 

Attn:  Data  Support  Division,  Building  206, 


Fort  McPherson,  GA  30303 1 

Commander,  Fleet  Intelligence  Center,  Europe, 

Box  18,  Naval  Air  Station,  Jacksonville, 

Florida  32212 1 

Commanding  Officer,  Naval  Air  Engineering 
Center,  Ground  Support  Equipment  Department, 

SE  314,  Building  76-1,  Philadelphia,  PA  19112  1 

Commanding  Officer,  Naval  Security  Group 
Command,  3801  Nebraska  Avenue,  N.W.  Attn:  GP22, 
Washington,  D.C.  20390 1 


Commanding  Officer,  Navy  Ships  Parts  Control 
Center,  Attn:  Code  712,  Meehan i csburg , PA  17055  1 

Headquarters,  US  Marine  Corps,  Attn:  System 
Design  and  Programming  Section  (MC-JSMD-7) 
Washington,  D.C.  20380 1 
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COPIES 


Commanding  Officer,  US  Army  Forces  Command 

Intelligence  Center,  Attn:  AFIC-PD,  Fort 

Bragg,  NC  2 8307 1 

Commander,  US  Army  Foreign  Science  and 
Technology  Center,  Attn:  AMXSJ-CS,  .20 
Seventh  Street  NE,  Charlot'tsville , VA  22212 — 1 

Commanding  Officer,  US  Army  Security  Agency, 
Command  Data  -Systems  Activity  (CDSA)  Arlington 
Hall  Station,  Arlington,  VA  22212 1 

Commanding  Officer,  US  Army  Security  Agency 
Field  Station  - Augsburg,  Attn:  IAEADP, 

APO  New  York  09  458 1 

Commander,  Fleet  Intelligence  Center,  Atlantic, 
Attn:  DPS,  Norfolk,  VA  2351  1 1 

Commander,  Fleet  Intelligence  Center,  Pacific, 

Box  500,  Pearl  Harbor,  HI  96860 1 

Air  Force  Operations  Center,  Attn:  Systems 
Division  (XOOCSC)  Washington,  D.C.  20301 1 

Commander,  Armed  Forces  Air  Intelligence 
Training  Center,  TTMNIM  (360  FFS) , Lowrv 
AFB , Co  80230 1 

Commander,  Air  Force  Data  Services  Center, 

Attn:  Director  of  System  Support,  Washington, 

D.C.  20330 1 

Commandcr-in-Chief , US  Air  Forces  in  Europe, 

Attn:  ACDI  APO  New  York  093  32 1 

Commander,  USAF  Tactical  Air  Command,  Langley 
AFB,  VA  23665 1 

Commander,  Space  and  Missile  Test  Center,  Attn: 

(ROC A)  Building  7000,  Vandonberq,  AFB,  CA 

93437 1 
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Naval  Air  Systems  Command,  Naval  Air  Station, 

Code  13999,  Jacksonville,  Florida  32212 1 

Commanding  General,  US  Army  Computer  Systems 
Command,  Attn:  Support  Operations  Directorate, 

Fort  Belvoir,  VA 1 

Defense  Documentation  Center,  Cameron  Station, 
Alexandria,  VA  2231  4 12 

TOTAL  1 59 
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This  Technical  Report  describes  the  installation  and  maintenance  of  the  NIPS 
360  Formatted  File  System.  It  describes  the  hardware  and  software  require- 
ments of  the  S/360  Operating  System  (OS).  The  functions  to  be  performed  to 
Install  NIPS  360  FFS  are  presented  and  a detailed  typical  2314  Installation 
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